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ABSTRACT 



The U.S. Army lacks a single automated fire support system. The goal of Army’s 
ongoing project of Advanced Field Artillery Tactical Data System (AFATDS) is to 
integrate all of its fire power under a single automated system to provide an efficient fire 
support in the battlefield. AFATDS is being implemented using the language ADA for 
battalion and above level. The problem for this research is to implement AFATDS for 
battalion (just for technical fire direction) level and below. In addition, we want to add a 
Graphical User Interface (GUI), use modem software engineering principles and add 
multitasking. 

The approach taken was to apply object-oriented paradigm for the design and 
development of the battery level of AFATDS using Microsoft Windows’ operating 
environment which provides (non-preemptive) multitasking and a GUI, and Borland C++ 
as the development tool. 

The results are as follows: The battery level software of AFATDS is implemented. The 
GUI provided a better interface which facilitates easier training [Ref. 17]. Multitasking 
allowed multiple firing missions to execute concurrently which was not possible with BCS. 
Object-oriented features of Borland C++ provided 60% improvement for GUI development 
than traditional programming languages. 
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I. INTRODUCTION 



A. BACKGROUND 

The mission of artillery is to provide and coordinate devastating fires, giving the 
maneuver commander the overwhelming combat power to win decisively and quickly 
anywhere and any time. Modem artillery has improved its effectiveness using new 
technologies with weapon and 0*1 systems. 

Technology developments, productivity, and battlefield concepts always force C*I 
components to work in an integrated environment to attain victory in the warfare. The 
current leading field artillery tactical automated system essentially based on TACFIREs/ 
LTACFIREs which are battalion level systems. The sub-systems of a TACFIRE/ 
LTACFIRE are Battery Computer Systems (BCSs) and various interfaces. It is an isolated 
system from other automated systems and services. Next step is to integrate all the tactical 
data systems of the army, namely Army Command and Control System (ACCS). Field 
Artillery Tactical Data System will be the subsystem of ACCS. 

Advanced Field Artillery Tactical Data System (AFATDS) which is an ongoing 
project being a sub system of ACCS is aimed to realize artillery portion of the integration. 
Since AFATDS had not been fielded yet, the concept of FATDS is preferred for the same 
scope of AFATDS for this thesis research. This integration will provide: 

• Centralized database which aims dumping databases to other computers to provide 
backup, exchanging data between relevant nodes and reducing data redundancy. 

• Faster fire support. 

• Saving resources. 

Field Artillery Tactical Data System (FATDS) is composed of several layers and 
independent interfaces. Layers are: 

• Battery level 

• Battalion level 
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• Corps level 

Interfaces are: 

• Digital message devices 

• Screens 

No matter how modem armies prepare themselves for future conflicts, there will be 
always surprises and unconditional requirements. Reprogrammability of automated 
systems provides flexibility to new requirements of a battlefield. At this point software part 
of automated systems needs programming paradigms which provide high degree of 
software engineering goals which are: [Ref.21: p.65] 

• Modifiability: The software system should be easily modifiable without causing other 
errors or complexity. 

• Efficiency: The software system should operate using the set of available resources, 
which are time and space, in an optimal manner. 

• Reliability: The software system should operate for long periods of time without human 
intervention. 

• Understandability: It is essential for modification and project management because of 
the need for coordination. 

In addition to those goals software developers have been experimenting with various 
methodologies to achieve some of the following goals: [Ref. 18: p.16] 

• Precise specification of the design. 

• Shorter code development phase. 

• Easier development of code. 

• Reusability of code. 

1. Advanced Field Artillery Tactical Data System 

AFATDS is an ongoing project for total fire support system for U.S. Army, with 
its fielding in FY’95. AFATDS will align targets with fire units and munitions and help 
manage survey and meteorological operations, movement and positioning and process of 
managing logistics. AFATDS will take into account all available fire support means, to 
include attack helicopters, tactical air, naval gunfire and offensive electronic warfare. It 
will employ sophisticated routines to recommend the right systems for the targets under 



2 



analysis and facilitate the synergistic integration of efforts. The heart of AFATDS’ 
development is software. 

The heart of AFATDS’ development has been the software. The first step in the 

AFATDS program was to establish the command and control functions of the fire 

support system, a detailed analysis that identified the inputs, the processes and the 

outputs. The results of this analysis have driven the AFATDS software. [Ref. 23: p.39] 

Major advantages of AFATDS in terms of software and hardware are seen as: 
[Ref.23: p.39-41] 

• Easy upgrades 

• No more Mutual Support Units (MSUs) 

• Comprehensive Functionality 

• Interoperability 

• No AFATDS military occupational speciality (MOS) necessary 

• Common hardware Army-wide 

• Large screen display 

• No more dedicated shelters 

• Fire Support Elements (FSEs) linked from battalion through corps 

• Lab-Top computers for Fire Support Officers (FSOs) and commanders 

A key aspect of AFATDS software will be its interoperability. As a component of 
ACCS, AFATDS will interface with maneuver, intelligence, air defence and combat 
service support systems. It is also being designed to interface with the Air Force and Marine 
automated systems and with the German (Adler) and British (BATES) systems. These 
interfaces will significantly enhance the total integration of the joint and combined team. 
[Ref.23: p.40] 

AFATDS has a distributed database architecture. The database of each AFATDS 
node will be maintained continually with the latest information. 

To maintain a full integration, portability and easy maintenance, AFATDS is 
using DoD’s standard programming language, ADA. AFATDS is conceptually evaluated 
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in 1989 and scheduled to be completed in FY’93 with fielding to the total force scheduled 
for FY’95. 



2. Battery Computer System 
BCS is defined as follows: 

An automated data processing system located in the firing battery. It consist of three 
major components: the battery computer unit, the power distribution unit, and 1 to 12 
gun display units. It is used to compute accurate firing data and as digital 
communications interface. [Ref. 10: Glossary-2] 

3. Motivation for Object-Oriented Approach 

My motivation for 0-0 approach in general: 

♦ Object-oriented approaches encourages the use of modern software engineering 
technology. 

♦ Object-oriented approaches promote and facilitate software reusability. 

♦ Object-oriented approaches facilitate interoperability. 

« When done well, object-oriented approaches produce solution which closely resemble 
the original problem. 

♦ When done well, object-oriented approaches result in software which is easily 
modified, extended, and maintained. 

♦ Object-orientation improves traceability. 

♦ Object-orientation improves the conceptual integrity of both the process and the 
product. 

B. OBJECTIVES 

The objective of this thesis is to create the battery level software of Field Artillery 
Tactical Data System analyzing the benefits of object-oriented implementation of both 
programming and database of the project in an environment which provides multitasking 
and graphical user interface. 



C. ORGANIZATION 

Chapters are organized into two groups: Programming language and database. Chapter 
II evaluates Object-Oriented Programming development languages and tools briefly. 
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Chapter III addresses the design features of programming phase. Chapter IV is a 
comparison of the Object-Oriented language implementation of subject vs. conventional 
programming languages. Chapter V evaluates the possible database management options 
for FATDS. Chapter VI addresses the design of the selected database management option. 
Conclusions and future works on FATDS are summarized in Chapter VII. 
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II. THE PROGRAMMING ENVIRONMENT, LANGUAGE AND APPLICAITON 

DEVELOPMENT TOOLS FOR FATDS 



The concept of Object- Orientation may not give any idea about its performance over 
other paradigms without considering programming environment, language and application 

development tools. 1 For this research I have chosen PC-based Microsoft Windows 3.1 as 
the programming environment, C++ as the Object-Oriented Language (OOL), and Borland 
C++ & Application Framework as the application development tools. Since the purpose of 
this research is to focus on the programming performance benefits of object-oriented 
implementation, the best selection of those elements is not discussed. 

Object-Oriented Design (OOD) and Object-Oriented Analysis (OOA) of FATDS will 
be discussed on the next chapter. Following sections discuss the characteristic of the 
selected elements. 

A. PROGRAMMING ENVIRONMENT 

When it comes to portability issue of a software, there are questions to be answered 
about programming environment. What will the application be used for? What kind of 
terminals will be used? Who will be the users? Which operating system will the application 
work on? What kind of devices will the application work with? Will the application work 
stand-alone or in networked environment? Does the application have to work with 
heterogenous subsystems in an network? There are many questions that a programmer 
faces with. I have taken PCs as the main hardware unit. Table 1 displays the system 
requirements of the 0-0 FATDS. The reasons for selections this environment are: 

• In addition to technologic developments, economical and administrative obligations 
makes all the uniform systems heterogenous. Especially huge systems do not tend to 
keep themselves uniform. PCs are unique examples to represent the variety of users, 
hardwares and software. Though its heterogeneous structure creates some problems - 
like training, hardware, software maintenance, either single or in a networked media 



1. When an object-oriented system is under construction, the architecture is foremost in impor- 
tance, just as it is in all other engineering disciplines. The development process is adapted to the 
architecture, and the tools are adapted to the process. [Ref. 15: p.26] 
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PCs are forcing companies to pay more attention to them. PCs word is developing with 
its new features and object-orientation is claimed for being familiar with these 
complexity. 

• PCs are more available computers to ordinary people. This means more people are 
familiar with PCs (which is important from the user’s train point of view) and there are 
sophisticated application tools for PCs too. 

• Its software and hardware are more economical than work stations. 

• This selection satisfies the objective of this research. 



TABLE 1: SYSTEM REQUIREMENTS OF 0-0 RAIDS 





Application 

Development,™ 


Application 

developmentoptimai 


CPU 


IBM-386 


IBM -486 


Display 


VGA, 2 color 


SVGA, 256 color 


Sound 


- 


- 


Operation System 


MS-DOS 5.0 & MS- 
Windows 3.1 


MS-DOS 5.0 & MS- 
Windows 3.1 


Memory 


2 MB RAM 


8 MB RAM 


Hard Disk Space 


80 MB 


120 MB 



1. Hardware Basics 

Hardware capabilities may boost the performance of the application, but there is 
no direct relation with the programming style for this research. Board, CPU, caching, 
display and other I/O devices have direct relations with either operating system or 
application requirements. 

2. Windows Basics 

The general structure of Windows programming naturally fits the OOP style. 
Everything on the screen is defined as a window, because each object has to have some 
common features. Each window inherits some of its features from other windows and add 
some specific ones. The data goes with a window is encapsulated into the window object. 
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Window objects are polymorphic, they can all receive common messages and take action 
that is appropriate for that window. [Ref.25: p.4] 

a. The GUI 

Does a user, who is supposed to use a computer, have to learn what the 
computer is? Or, should the computer be designed regarding a specified user group? 
Practically both questions have positive answers. Needs and technology determine each of 
its ratio in an application. 

Most computer users are familiar with Windows’ GUI and all Windows 
applications have consistent interface. Consistency is one of the important factors which 
helps a user to adopt a new application in shorter time. 

Though every environment provides different GUI in different degrees of 
graphicism Windows provides all the basic GUI tools. These are the most common 
graphical elements: 

» Icons 

• Fonts and text formatting 

• Charts and graphics 

• Menus 

One of the graphical elements of Windows Application Interface (API) is 
controls which represents an event or information source for events. Controls are mainly 
used for user input. The leading feature of controls is to make the user remember some 
information but not to memorize for recalling. The controls are: 

• Buttons 

• Check boxes 

• Combo boxes 

• Static/dynamic edit fields 

• Radio buttons 

• Custom controls 

There are high level graphical elements too: 

• Drag-and-drop mechanism 

« Hot spots in text or graphics to do something when selected. 
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Those were the just the elements of Windows GUI. The problem is to produce 
something that the user will understand and use it easily. 

b. Event-Driven Applications 

The only communication link between a user and a terminal is Input / Output 
(I/O) actions. Procedural interfaces provide I/O in either command line or question-and- 
answer form. In either case, the application gets some input, goes off to process it, and 
produces output. The application is the boss, and the user acts as an intelligent database 
server. Menu-driven applications takes some database burden of the user. [Ref. 17: p.39] 

Event-driven applications act on events coming from a variety of sources. 
The events may come from controls that the user can activate, from other programs, or from 
devices such as the clock or communications port. 

Event-driven applications are not specific only to Windows, but almost all 
Windows applications are based on this style. Event-driven programming brings a different 
approach to the design and implementation of an application. Events leads the way, so 
establishing a GUI generally is the first phase of implementation. Just a GUI, without a real 
code behind it, serves as a prototype of the application. This eliminates other third party 
tools for rapid code prototyping. 

c. Multitasking 

Windows 3.1 provides a non-preemptive multitasking environment. This 
feature is one of the key factor for the end-user. The user can run more than one application 
simultaneously. 

d. Device Independence 

This feature is important for both user and programmer. The device 
dependency is hidden away in the Windows’ Graphics Device Interface (GDI) and deice 
drivers that are either bundled with the retail Windows or supplied by the device 
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manufacturer. Windows program developers can ignore about devices, they know that their 
application will work with all the devices that are introduced to Windows. 



For programmers in non-Windows environment, program output can be the most 
challenging task of the entire application. Idiosyncrasies of a wide variety of devices 
must be discovered, resolved, and properly handled in the code. For small developers, 
just obtaining the necessary manuals and use of devices for testing can prohibitively 
expensive Under Windows, all these problems simply goes away. [Ref. 19: p.78] 

e. Elements of a Windows Application 

A typical Windows applications has these elements: A main window contains 
a title bar, menu and a client area. The client area serves as a canvas that the application can 
draw on. Main window may have child windows. Child window looks sometimes as a 
control or sometimes another client region. Dialog boxes are for either information display 
or input purposes. Dialog boxes contain a number of controls, such as buttons, radio boxes, 
etc. 



/. Dynamic Link Libraries (DLL) 

DLLs are one of the advanced features of Windows. Normally most functions 
have been statically linked to applications. When a library or object code is used the 
executable versions of the functions contained in the code are brought in to executable file. 
[Ref.20: p.48] Since this is a static linking, multiple versions of the same function may exist 
in the executable file. Any modification on the library functions require relinking of the 
application. So the whole application is replaced. 

Dynamic linking occurs at run-time. Application is just introduced to the 
function and in which. DLL file its implementation is placed. The executable file does not 
carry the object code. When the executing program makes a call to a dynamic link function, 
Windows checks to see whether the function is already in memory. If it is in memory 
Windows increases the in-use counter for this library by one and passes execution to the 
new memory location. If the function is not already in memory, Windows tries to find a file, 
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with a .DLL extension, that contains the desired function. Windows then loads the function 
into memory. [Ref.20: p.49] 

The only disadvantage of DLLs is that .DLL files should be ported with the 
application while the advantages of DLLs are: 

♦ Downsize the executable code size and compile-link time. E.g., OFIRE.EXE file was 
more than 400K Ion before using .DLLs, and it become almost 150K long executable 
file. 

♦ Provide the application to run on computers that have a limited amount of memory. 

♦ Ease the maintenance of the code. When a DLL file is updated, it is enough to replace 
that .DLL file without linking the whole code. 

♦ Make interchangeable modules. [Ref.25: p.66] 

B. PROGRAMMING LANGUAGE 

I have selected C++ as an OOPL. It is not the only OOPL, but it is one of the OOPLs 
that supports all the 0-0 features. One of the leading reasons which makes me select C++ 
is its commercially availability. 

For better or worse, the real winner today is C++, which attracts large groups of 
programmers at the largest companies and is used on thousands of projects in industry. 
[Ref. 15: p.26] 

Stroustrup lists the language features of C++ as: 

♦ C-based, object-oriented extension of C. 

♦ Class concept and class-based object-oriented paradigm. 

♦ Data abstraction and data encapsulation facilities. 

♦ Mechanism for data abstraction hierarchies. 

♦ Strongly typed. 

♦ Function and operator overloading. 

♦ User-controlled memory management. 

♦ Facilities modeling multiple inheritance. 

♦ Support polymorphism. 

♦ Type-safe linkages. 

♦ Abstract classes. 

♦ Exception handling mechanism. 

♦ Used for general purpose applications as well as simulations development. 
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♦ Can be use to model conceptual solutions. 

C. APPLICATION DEVELOPMENT TOOLS 

Borland provides all the tools that is necessary to produce Windows programs. 

1. Application Development tools 

Borland C++ 3.1 and Application Framework has the following tools: 

♦ An ANSI C and C++ global optimizing compiler 

♦ A DOS protected-mode interface (DPMI) compiler and programmer’s platform 

♦ A Windows-base integrated development environment (IDE) 

♦ A graphical source browser (ObjectBrowser) 

♦ A utility for tracking Windows messages (WinSight) 

♦ A debugger for DOS and Windows applications (Turbo debugger) 

♦ A profiler for DOS and Windows (Turbo Profiler) 

♦ The Turbo Assembler 

♦ The Resource Workshop 

♦ A library of C++ classes to simplify Windows application development 
(ObjectWindows) 

♦ The EasyWin library for porting DOS programs to Windows 

» The Turbo Vission application framework for DOS applications 

♦ Source code to the runtime library 

2. Language 

Borland compiler runs in protected mode, so large programs and libraries do not 
require extensive swapping. Precompiled header are supported. Because the headers for 
Windows programs tend to be quite large (windows. h alone is over 120K), this Borland 
C++ feature can increase compile times by a factor of ten. [Ref. 19: p.xviii][Ref.25: p.5] 

Borland IDE editor provides to open multifiles simultaneously as well as large 

files. 
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m. OBJECT-ORIENTED PROGRAMMING DESIGN OF FATDS 



A. INTRODUCTION 



Object-oriented programming should follow Object-Oriented Analysis (OOA) and 
Object-Oriented Design (OOD). Though 0-0 paradigm goes back two decades, OOA and 
OOD methodologies are not mature enough. [Ref. 14: p.22] Discussions are still continuing 
about a perfect methodology for both OOA and OOD. The goal of OOA is still the same: 
the development of an accurate and complete representation of the problem domain. 
[Ref. 14: p.26] The problem is that there is no standard OOA methodology. I have selected 
Coad & Yourdon OOA [Ref.6] and Booch OOD [Ref. 4] to build basis for 0-0 
methodologies of this research. 

1. Coad and Yourdon OOA 



This model defines the problem domain in five consecutive steps where each step 
builds on the previous step. The steps are: [Ref. 14: p.27] 

• Define objects and classes: Look for structures, other systems, devices, events, roles, 
operational procedures, sites, and organizational units. 

• Define structures: Look for relationship between classes and represent them as either 
general-to-specific structures. 

» Define subject areas: Examine top level objectives within whole-to-part hierarchies and 
mark these as candidate subject areas. Refine subject areas to minimize 
interdependencies between subjects. 

• Define attributes: Identify the atomic characteristics of objects as attributes of the 
object. Also look for associative relationships between objects and determine the 
cardinality of those relationships. 

• Define services: For each class and object, identify all the services it performs, either 
on its own behalf or for the benefit of other classes and objects. 

Coad and Yourdon uses the following tools for OOA: 

• Class and object diagram 

• Object state diagram 

• Service chart 
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2. Booch OOD 



Booch is the pioneer of OOD. Booch’s methodology was originally ADA 
language specific, but he adopted his methodology to 0-0 completely. He recommends not 
a specific ordering of analysis plus design phases. The strategy should be “analyze a little, 
design a little” [Ref.4: p.201]. Because there is no certain border between analysis and 
design of a problem to jump from one to another. Design process should be worked with 
iteratively and incrementally, augmenting formal diagrams with informal techniques 
appropriate to the problem at hand. Booch’s four major design steps are [Ref. 14: p.32]: 

♦ Identify classes and objects: Identify key abstractions in the problem space and label 
them as candidate classes and objects. 

♦ Identify the semantics of classes and objects: Establish the meaning of the classes and 
objects identified in the previous step using a variety of techniques, including creating 
“ scripts ” that define the life cycles of each object from creation to destruction. 

♦ Identify relationships between classes and objects: Establish class and object 
interactions, such as patterns of inheritance among classes and pattern of cooperation 
among classes and patterns of cooperation among objects. This step also captures 
visibility decisions among classes and objects. 

♦ Implement classes and objects: Construct detailed internal views of classes and objects, 
including definitions of their of their various behaviors (services). Also, allocate 
objects and classes to modules. 

Booch uses the following tools for OOD: 

♦ Class diagrams and class templates 

♦ Object diagrams and timing diagrams 

♦ state-transitions diagrams 

♦ operation templates 

♦ module diagrams and templates 

♦ process diagrams and templates 

3. My OOA and OOD Strategy 

As it is indicated above I carried out analysis and design together. The reasons are: 

♦ There is no distinct border between analysis and design. Switching to design to late may 
cause waste of resources while switching too early may cause not to identify the 
problem. It is more flexible to do them together. 

♦ The design may not reflect the capabilities of the system environment or the 
requirements of the user completely. Instead of using external software prototyping 



14 



tools, GUI-based prototyping which could be performed at various steps of system 
development, provides realistic and early evolution of the design. Each time after 
receiving feed-backs from the consumer, it could be necessary to modify the analysis 
again. 

• There are diverse design options for the project. Not all the design options are derived 
from the analysis. At a point in the project it would be necessary to modify the design 
and the analysis process as well. 

• There may appear some constraints and force to change to alternate designs. E.g., size 
of code may force the system hardware’s memory limitations. 

Above conditions are valid not only for 0-0 methodologies, but also for non- 
object-oriented ones. After evolution of a system, if a modification is required, then it will 
be necessary: 

• To add a/some new part(s) into the system and/or, 

• To throw away a/some part(s) of the system and/or, 

• To modify a/some part(s) of the system 

Object-oriented systems adds another option for creation or modification of a 
system: Reuse. At the beginning of a large project development or on small projects the role 
of reusing may not be so important, but during the development of phase and for large 
scaled projects reusing begins to save resources. Assuming that old components of the 
system are well tested, other objects which are created by inheriting those old objects are 
most likely be trusted objects. It will take shorter time to test new objects. 

First product after a brief analysis was the GUI of the project. The design of GUI 
is an application-independent technology for which a number of useful libraries of reusable 
software components have been developed. So, GUI’s development was faster than the 
applications. FIGURE 1 on page 16 show the cycles for 0-0 FATDS project development. 
This cycle is named as Model-Based Project Development Cycle (MBPDC). The 
product(s) is always tested with the real-life requirements during the development cycle, 
even though the product(s) is not a complete one during the process. First analysis helps to 
form classes and objects to create the first form of the product which is just the GUI. 
Modeling and testing begins with this GUI which serves as a prototype. This is more than 
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a usual prototype which simulates a real-life application, but it is the real-life application. 
Modeling leads the design, so the analysis. 




Figure 1: Model -based project development cycle for 0-0 FATDS 



There is always a working model. Functionality of the model is limited during the 
development cycle and it completely matures qt the end of the MBPDC. 

The nature of event-driven programming and its compatibility with OOP helps to 
establish separate or independent event modules. This event inter-independency and 
reusing makes the modification easier at any time of MBPDC. 

4. Naming Conventions 

For a more readable code I have used long meaningful names for variables, 
enumeration types, classes, and objects etc. E.g., SubFireCallWndCls and RadioGrid. 
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I have also embedded small identifiers into the names to distinguish them from 
others. In addition, I named an instance of a type or class almost the same with its 
instantiator, e.g., SubFireCallWndCls is a class type and SubFireCallWnd is instance of 
that class. Table 2 on page 17 displays a list of embedded codes which are used for naming 
in this research. 



TABLE 2: EMBEDDED CODES FOR NAMING 



*Cls 


Class deflation 


*DlgCls 


Dialog window class deflation 


*Dlg 


Dialog object 


*WndCls 


Window class defination 


*Wnd 


Window object 


Button* 


Button control object 


Check* 


Check box control object 


Combo* 


Combo box control object 


Edit* 


Edit control object 


List* 


List box control object 


Radio* 


Radio box control object 


h* 


Any kind of object handler 


ID_* 


Identifier for window objects 


♦Type 


Enumeration type definition 



B. ANALYSIS 

1. FATDS System Requirements 

FIGURE 2 on page 18 displays a block diagram for Firing Support (FS) portion 
of FATDS. The basic function of the system is to make the guns fire with computed data 
against the targets on the battlefield which are asked from artillery to be destroyed. 
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Each of the block elements could represent more than one of that element and in 
diverse organizational structures. The automation of the each structure may differ too. 
Regarding the communication tools of any kind and battlefield irregularity, the system 
should keep to work with acceptable functionality. The major system elements are: 

♦ Guns: They are organized in platoons, batteries or battalions as basic firing units. The 
number of guns and models of them vary. 

* Fire direction centers: The element of a command post consisting of gunnery and 
communication personnel and equipment by means of which the commander exercises 
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fire direction and/or fire control. The fire direction center receives target intelligence 
and requests for fire and translates them into appropriate fire direction [Refill : p.G- 
8]. FDCs are functional at platoon, battery and/or battalion levels. 

• Target acquisition elements: There are various target acquisition elements. FA 
battalion 52, targeting officer, fire support team, aerial fire support observers, combat 
observation/ lasing team, survey platoon, weapons-location radar, moving-target- 
locating radar and electronic warfare are all the elements for target acquisition.! Ref. 7: 
P-5-1] 

• Command and control elements: From Fire Direction Officer (FDO) at platoon / 
battery level to higher tactical headquarter who plans and controls the fire are included 
in this block. Their role is tactical rather than technical. These elements make decisions 
about “Who will fire?” , “Which target(s) will be fired?” , “What kind ofweapon(s) & 
ammunitions) combination will be formed?” , “When will be the firing time? Different 
levels of command may have different control responsibilities on various operations. 

• Survey elements: These are technical elements too. Survey elements provides met 
messages, target intelligence, and land survey support for the FDC and command 
control elements. 

• Database: Local or centrally located, distributed or single database system is the main 
information source of the system. To avoid waste of resources, central databases are 

encouraged. 

• Timer: This is just a control element which sets the timed fires or other events. All the 
elements should follow a central time function for synchronization. 

The following inputs exists: 

• Fire call 

• Fire order 

• Fire commands 

• Fire orders 

• Firing reports 

• Firing table 

• Gun and ammo status 

• Message to observer (MTO) 

• Met messages 

• Subsequent fire calls 

• Status reports 

» Subsequent fire call 

• Surveys 

• Target acquisition 

• Target info 

• Target lists 

• Target update 
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• Time 

2. Defining the Boundaries of the Problem 

Field Artillery Tactical Data System is sub-part of the army’s integrated 
battlefield automation program. Since this is a huge and sophisticated program this research 
has captured only Field Artillery (FA) Battery Fire Direction level regarding its FS portion. 
FIGURE 3 on page 20 displays the block diagram of battery level tactical data system /FS. 
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FIGURE 4 on page 21 displays the block diagram for battery fire direction 
system. There are two major functional units, firing chart and computation. Firing chart 




holds the coordinates of: 

• Batteries (gun positions) 

• Radars 

• Observation posts 

• Registration points 

• Targets 
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• Checkpoints 

Firing chart produces linear and angular distances of any two points, which are on 
the chart, for computation. 

After having chart values Computation transfers them into firing commands and 
sends them to the Firing elements (guns). Computation reflects its computational results on 
Record of Fire (ROF) form. Computation produces the firing commands regarding: 

• Time: At my command, When ready, Time on Target (TOT). 

• Firing techniques: Surveyed firing, copperhead munition firing, nuclear munition 
firing, smoke projectile firing, illuminating projectile firing, MET+VE technique, 
registration, Fire for Effect (FFE), special corrections. 

• Firing tactics: Attack of large targets, target analysis, safety procedures, munition 

effects. 

• Ballistics (interior and exterior): Nature of propellant and projectile movement, muzzle 
velocity, meteorological conditions, dispersion. 

3. Defining the Objects and Classes 

Followings are the classes derived from the block diagram of the system and/or 
description of the diagram elements. 

• Dispersion 

• Chronometer 

• Fire commands 

• Fire Calls 

• Subsequent fire calls 

• Fire order 

• Message to observer 
» Computation 

• Firing report 

« Gun and ammo status 

• Target database 

• Firing report database 

• Met messages database 

• Guns and munitions database 
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4. Define Subject Areas 



Classes are grouped into two main subject areas: Firing chart and firing 
computation. Those groups will be the basis for the design of GUI. The classes, which have 
been formed so far, are nothing to do with GUI but they will be re-organized after the events 
of the GUI is determined. 

C. GRAPHICAL USER INTERFACE DESIGN 

So far two functional unit appeared. They will be named as OFire for firing 
computations and OChart for firing chart manipulations. GUI design was the backbone of 
the analysis phase. They have been accomplished together. Since the GUI served as a 
prototype of the final product, it was useful determine the events for objects, classes and 
the relationships of them. 

1. Design Considerations 

The design of a GUI is being effected not only by the capabilities of the system’s 
environment, but also by the following criteria. 



a. The User 

Since both OChart and OFire are specific applications for a Field Artillery, 
the number of the users is limited with the FA Fire Direction Center (FDC) personnel. 
Training requirements are still one of the major issues with the user. Windows GUI 
environment eliminates some of the training problems and add these features: 

• The user does not have to memorize everything. He/she inputs most of the data by 
selecting, not by entering. He/she is not overloaded with decision making points at the 
same time, but he/she is asked to do only when necessary. 

• The GUI is forgiving for the user decisions, it is possible to take decision steps back. 
So, the system is less error-prone. 

• Even though the user knows nothing about Dos/Windows or any other OS which 
operates a window style environment, this will help the user to adapt the software in a 
shorter time than the command line style interface. There is no certain educational 
background except reading&writing. 
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b. Consistency 

One of the most important issues with GUI is consistency. Each part of the 
applications should be consistent with: 

• Other issues of the user’s way of life: Button shapes and behaviors, sounds and 
graphics for warnings, etc., should be consistent with the user’s daily life. 

• Other applications in that OS environment: The user should transfer some of her/his 
experiences from one application to other. This helps to shorthen the training and 
adaptation period, besides prevent some errors which are source from controversies. 

c. Screen-Layout Issues 

Menu system, naming terminology, semantic grouping of items, fonts and use 
of color are main points of screen-layouts. All of these factors contribute to success of a 
software, so the victory. 

d. Customizing 

To allow a user to customize an application makes easier to use that 
application in accordance with that user’s condition only. To provide standardization and 
easier adaptation of users to the applications customization is not allowed for OChart and 
OFire applications. 

e. Input and Output Devices 

Main input device for Windows applications is mouse as well as keyboard. 
Voice activated commands may be used with some limitations too. Lessening the role of 
keyboard for data entry decreases the training needs and increases the performance of the 
application 

/. On-Line help and Tutorials 

Application should feed the user with necessary information which is about 
what he/she is doing, or to do etc., at a time when he/she needs. Windows allows a standard 
style help system which is context-sensitive and topic-navigated. 
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g. Error Handling 



People are tend to make errors even if they are trained on that topic. Windows 
event-driven environment makes it easier to add check points and warnings for each 
reaction of the user. 

2. OFire 

All the windows and dialog boxes designed for the OFire application are 
displayed on APPENDIX-D. 

3. OChart 

All the windows and dialog boxes designed for the OChart application are 
displayed on APPENDIX-D. 

D. OBJECT-ORIENTED DESIGN (OOD) 

1. Identify Classes and Objects and Their Semantics 

The classes have been formed with their actual names and grouped into 
programming modules. Not all the classes have been formed at the same time and those 
classes are the last phase of the development. 

a. The Classes for OFire 

(1) bursts, h 

• SheafWndCls 

• BurstsWndCls 

(2) button2.h 

• Button2Cls 

(3) command.h 

• CommandWndCls 

• ChronoWndCls 

• FireCommandsWndCls 
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• InfoWndCls 

• SubFireCallWndCls 

(4) fire.h 

• FireCallDlgCls 

• PolarWndCls 

• ShiftWndCls 

• GridWndCls 

• SuppressionWndCls 

• FireOrderDlgCls 

• MTODlgCls 

• SubFireCallDlgCls 

• TOTAtTimeDlgCls 

• TOTAfterTimeDlgCls 

(5) globals.h 

• ComputationCls 

(6) report, h 

• ReportWndCls 

• TextWndCls 

(7) select.h 

• SelectionWndCls 

b. The Classes for OChart 

(1) abslist.h 

« genAbstractList: Implements an abstract class of linked lists. 

(2) Chart.h 

• GridSetupDlgCls 

• TargetSetupDlgCls 

• GunSetupDlgCls 

• NewEntryDlgCls 

• NewFromEntryDlgCls 

• GunlnputDlgCls 

• TargetlnputDlgCls 

• TargetDBDlgCls 

• GunDBDlgCls 
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(3) gen21ist.h 

• genOdList 

• genUdList 

(4) globals.h 

• GlobalCls 

(5) gundb.h 

• GunDBCls 

(6) info.h 

• SelectionToolCls 
« DistanceToolCls 

• NewToolCls 

• NewTToolCls 

• SearchToolCls 

• PickToolCls 

• InfoWndCls 

• ToolBarWndCls 

• CanvasWndCls 

(7) Targetdb.h 

• TargetDBCls 

2. Identify Relationship Between Classes and Objects 

FIGURE 5 on page 28 and FIGURE 6 on page 29 display the class relationships. 
In those figures system and user-defined classes are distinguishable. All the dialog or 



27 



window classes which helps to develop GUI, inherit most of their behaviors from their 
parent classes. 




3. Implement Classes and Objects 

Complete listings of header files are provided on APPENDIX A and APPENDIX 
B. 
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DBGunCIS 
DBTargetCIs | 
WParadoxRecord | 
WParadoxTable 
WParadoxEngine | 
DBTable_F_cis~~| 
ComputationCIs | 



Figure 6: Class hierarchy for OFire (ii) 



E. FILE ORGANIZATION 

1. File Organization for C++ Windows Programming 

FIGURE 7 on page 30 shows a sample file organization for a a simple C++ 
Windows program. Every class is defined in a header file and its implementation is placed 
in source files. One of the exception to this rule is Main file. There are two class definitions 
for a main Windows program and a main program function. One of them inherits from 
TApplication class and it registers the instance of the application to Windows system. The 
other one inherits from TWindow or TDialog class and it creates a window for the 
application. The declarations of those classes are generally placed in Main Source File 
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since they will not be called or instantiated by anyone. Only main program functions 
instantiates them and use it.f 




Figure 7: C++ development file organization for Windows environment 



Main Header File is used for some definitions, and dialog box class declarations. 
If some objects are placed in .DLL files, its header files are still kept like other built-in class 
libraries. The only difference for their usage is that, it should be told to the compiler the 
implementation of any class or function is placed in .DLL files. That specific.DLL file will 
only be searched during run-time. 
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Another file which is specific to Windows is resource file. It is a text file and holds 
the resource descriptions of: 

• Accelerators 

• Bitmaps 

« Cursors 

• Dialog boxes 

• Fonts 

• Icons 

• Menus 

• String tables 

Resource file can be created either manually or with Resource Workshop. It is not 
in a specific language, though it is in a special text format. Borland C++ compiler compiles 
it with a special compiler and links it to the code. All the resource code is placed in the 
executable file in separate modules. This allows the Resource Workshop application to 
open and modify the resources of an application without disturbing the executable’s 
functionality. Eliminating compile and linking efforts, this makes the maintenance easier 
from the resource point of view. 



31 



2. FATDS’s File Organization 



The file organization of FATDS is shown on FIGURE 8 on page 32 and FIGURE 
9 on page 33 . 



7 fire.cpp 


bursts.h 


7 bursts.cpp ^ 


button2.h 


(7 button2.cpp ]) 


command. h 


7 command.cpp^ 


dbgun.h 


7 dbgun.cpp 


dbtarget.h 


(7 dbtarget.cpp ^ 


dbtblj.h 


(7 dbtbl_f.cpp ^ 


fire.h 


(7 dialogs.cpp 


globals.h 


(7 globals.cpp 


pxengine.h 




report.h 


(7 report.cpp 


select, h 


(7 select. cpp 


paradox, h 




pdoxeng.h 




pdoxrec.h 




pdoxtab.h 




wstr.h 





fire.prj 



fire.rc 



fire.def 




Figure 8: File organization of FATDS / FS (ofire) 
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charl.cpp 


chart.h 


(" dialogs. cpp 


gen2list.h 


gen2list.cpp 



r gridset.cpp 



C info.cpp 
f dbtarget.cpp^) 

Q dbgun.cpp 



chart.prj 

chart.rc 



chart.def 




dbtarget.h 


dbgun.h 


abslist.h 


globals.h 


pxengine.h 


defines. h 


globals.h 


wparadox.h 


wpdoxeng.h 


wpdoxrec.h 


wpdoxtab.h 


wstr.h 



Figure 9: File organization of FATDS /FS (ochart) 
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F. DESIGN DECISIONS FOR DLLs 



Borland C++ and Windows both have limited number of DLL files. Each application 
adds new DLL files to the system. The more an application uses DLL files the more 
performance it provides to the user. 

DLLs, necessary for out prototype are: 

• Custom controls, e.g., button2. 

• Database engine and other database service files which works with database engine. 

G. INITIALIZATION FILES 

Some objects in the applications may need to initialize some of their attributes before 
they are created and store them back, just after they are deleted. The values of those 
attributes should be stored in a persistent environment. C++ does not provide a built-in 
database management system (it does not have to) to store such values. There are three 
options to do that: 

• To use a separate DBMS 

• To use binary files using C++’s stream libraries 

• To use text files using C++’s stream libraries. 

First option is not beneficial for such short amount of data. It increases the size of code 
and implementation time. Binary files store and retrieve the objects keeping their 
abstraction or their type. 

For the OChart application, it runs using the last values of which just before it is 
closed. E.g., the user will probably want to open the firing chart with the same window size, 
at the same screen location, with the same scale and customization etc., as he/she close it 



34 



for the last time. Each object stores these kinds of persistent data in a * . sav file. One file 
for each application is enough and it should be binary file. 



Some persistent data which is useful for customization should be stored in text files 
with * . ini extensions. These kinds of data are mostly in string type or don’t cost much to 
convert to/from other types. Its difference from * . sav files, * . ini files: 

♦ Can be edited by the user without running the application using any kind of text editor. 

• is useful to feed any type of control, like combo boxes and list boxes, with persistent 
data. Any object which can easily reach these data without worrying about data 
structure. 



IV. COMPARISON OF OBJECT-ORIENTED VS. CONVENTIONAL 
PROGRAMMING PERFORMANCES 



A. INTRODUCTION 

As the need for the computers increases, so do the problem domain for the software. 
The software engineering goals, which are described in the first chapter, are sourced from 
the software problem. Some of the problems can be stated as [Ref.3: p.8]: 

• Responsiveness: Computer-based systems often do not meet user needs. 

• Reliability: Software often fails. 

• Cost: Software costs are seldom predictably and are often perceived as excessive. 

• Modifiability: Software maintenance is complex, costly and error-prone. 

• Timeliness: Software is often late and frequently delivered with less than-promised 
capability. 

• Transportability: Software from one system is seldom used in another, even when 
similar functions are required. 

• Efficiency: Software development efforts do not make optimal use of the resources 
involved (processing time and memory space). 

0-0 is not a silver bullet to solve those problems, but it has important features which 
has more meaning in skillful hands. Following sections evaluates various criteria to put 
forward the compared performances of 0-0 against nonO-O programming environments. 

B. COMPARISON CRITERIAS 
1. Modifiability 

No software is perfect. There could be always errors. Even though a software 
meets requirements of the user, later the user will probably demand something more from 
that software. Modification is needed for two reasons: 

• Errors 

• New requirements on the software 

Modification is almost similar to fixing or modifying a car. If the system is 
complex, modification should be located on the design job first. The role of design job or 
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architecture of the system is to avoid getting lost in the complexity of the system. So the 
design should be consistent with the system. There are two step for modification: 

• Locating the modification point(s) in the software system 

• Performing the modification 

First step is mostly effected from the design tools, while the second one from 
programming language environment. The keywords for both steps are clarity and 
consistency. 

Windows programming environment provides some modification easiness of its 
own: Control tools (like buttons, string table, accelerations etc.) which can be observed 
from Borland C++ Resource Workshop, can be modified without even recompiling the 
whole software. 

The relationship between major 0-0 features and modification will be discussed 
on next section. 

a. Encapsulation 

Modification may come with some extra problems like: 

• Increasing the complexity of the system unnecessarily 

• Endangering integrity of data in the modules of the software 

In C++, providing encapsulation, every object is responsible of its data and 
detail of its implementation. Mostly, objects hides their data from outer world, they just 
allow outer objects to use service or member functions to reach specific data of their own. 

b. Inheritance 

Multiple inheritance is still in dispute about whether it is a strength or move 
of a “white elephant”, in 0-0 world. C++ supports multiple inheritance and should be used 
carefully, since it could be a big problem for modification. All the inheritance concept 
mentioned in this research is single inheritance. 
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Suppose that FireCommandsWndcis is a class and has member functions of 
f 1 ( ) , f 2 ( ) , f 3 ( ) , and so on. After a time it become necessary to make some modifications: 
changing the implementation of f 1 ( ) , adding a new behavior of f new ( ) . 

In the conventional paradigms, modules, which does not reflects the user 
requirements, should be either: 

♦ Thrown away, since they are not functional any more: If a replacement is required, a 
new module should be created from scratch. Old code is wasted and becomes 
completely unfunctional. 

♦ Modified: Software integrity should be preserved. Modified part of the code is lost. 

For the 0-0 paradigm, inheritance is another chance for reusing of the old 
code: Creating another class which inherits from FireCommandWndcis, overloading f l ( ) 
and having fnew( ) member function. Big portion of the old code is still functional and the 
rest can still be used by others. Since the old code is preserved, its reliability is preserved 
too. 



c. Polymorphism ( dynamic binding) 



Consider the following sample codes derived from the OChart application: 
A base class: 

class SelectionToolCls 
{ 

public : 

virtual void DoMouseDown ( long , long); 
virtual void DoMouseMove ( long, long) ; 



Child classy 

class DistanceToolCls : public SelectionToolCls 
{ 

public : 

virtual void DoMouseDown ( long , long); 
virtual void DoMouseMove ( long , long); 
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} ; 



Child class 2 : 

class NewToolCls : public Select ionToolCls 
{ 

public : 

virtual void DoMouseDown ( long , long); 
virtual void DoMouseMove ( long , long); 

} ; 

DistanceToolcis and NewToolCls are two sample classes with their base 
class of Select ionToolcis. They all represent a button on the screen. If a user selects one 
of them then an appropriate action should take place. Those actions are the same by title 
but different by implementations. Since the interaction of the user can not be estimated in 
advance, conventional methodologies search for the user’s interaction by case-like 
statements/functions. Each time the user’s decision is wondered then it is searched. Adding 
and deleting buttons make the user to update all the case groups. 

Dynamic linking or polymorphism makes modification easier and more 
reliable than conventional paradigms. Declaring a host pointer: 



SelectionToolCls *Selection; 

DistanceToolcis DistanceTool ; 

NewToolCls NewTool; 

And assigning sub-object to the pointer when needed: 

Selection = &Distance; 
or 

Selection = NewTool; 

Above assignment are made after user’s interaction. Within the code: 

Selection->DoMouseMove ( . . ) ; 
or 

Selection->DoMouseDown ( . . ) ; 
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The pointer selection is independent from address object. It will be 
bounded dynamically and will retrieve appropriate class’s virtual member function (which 
is last assigned one to the pointer). When a modification is needed, creating a new child 
class and making an assignment under a button control is sufficient. Polymorphism makes 
the code shorter and clear, so helps the modification. 

2. Efficiency 

The goal of efficiency implies that a software system should operate using the set 
of available resources in an optimal manner [Ref.3: p.30]. Resources are grouped into two: 

♦ Time resources 

♦ Space resources 

The use of resources is mostly dependent on hardware and the algorithm which is 
used in the software. The 0-0 programming paradigm does not have significant impact on 
efficiency. 

3. Reliability 

The software system should operate for long periods of time without human 
intervention. This gains more importance especially for mission-critical applications. 
Software engineers accept that there is no perfect software. The goal to minimize the 
failures which endanger the mission. For increasing reliability, OOPLs provide: 

♦ Object structure: Provides realistic mapping from real-world objects to form the 
problem domain. 

♦ Encapsulation: Protects the objects’ own privacy and provide data integrity. 

♦ Reuse of reliable objects: Assuming the old objects are well-tested, reusing of them via 
inheritance eases the testing of the new object(s). 

4. Understandability 

Understandability is essential for modification and project management, because 
of the need for coordination. Understandability is dependent upon programming language 
and tools. Language is the way to express the real-world solution [Ref.3: p.31]. 
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One of the fundamental differences, which distinguishes 0-0 from nonO-O is 
mapping from problem domain to software solutions. Conventional methodologies 
decompose a system into modules for which each module represent a major step in overall 
process. Object-oriented methodology keeps the real-world objects or decompositions in 
their abstraction and represent them in objects. “Call for Fire” process which is send from 
an observer to FDC for being a fire request, can be represented as an object in 0-0. It has 
verbal operations and noun phrases, which describe its behaviors just like the real-world 
objects. It keeps its unity and communicates with other objects. The benefits of objects: 

♦ Similarity of objects to the real-world objects makes disowning of 0-0 projects easier 
and more readable. 

♦ Dealing with object modules is similar to real-world objects, so, maintains, 
modification and extensibility of the software is easier then conventional ones which 
are created by using top-down structured design. 

♦ For large projects, it is easier to decompose the job without losing semantics of sub 
modules. This increases the reliability of subparts. 

5. Code Size and Cost 

One of the tools to estimate the cost of a software is Cocomo 1 . Cocomo is a lines- 
of-code-based costing model that estimates the software development cost. The cost is 
determined with the formula: 

SM = A * KSLOC fi 

In the equation, SM is the number of staff-months which is required to complete 
the system development; A is an empirically derived number that converts 1000 lines of 
code into its equivalent cost in SM; KSLOC is the lines of source code (expressed in 
thousands); and B is a factor that compensates for the nonlinear nature of software 
development. [Ref. 19: p.363] 

The role of 0-0 in decreasing the Line of Code (LOC) shows itself with its reuse 
capability. Reusing becomes more effective when: 

1. Barry Boehm’s Constructive Cost Model to estimate effort, man power, and so on [Ref.2]. 
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♦ The size of code (or project) is too large (in ten thousands of LOC) 

• Application completely or partially use high degree of reusable software components, 
like GUI component. 

One point should not be disregarded, reuse , like cache memories, provides 
diverse performances on different problem domains and it mainly depends on design. 

6. Portability 

Portability is mostly dependent on both language and environment. 0-0 
paradigm contributes to portability with its encapsulation feature. 

FIGURE 10 on page 42 displays a sample Borland C++ include file which 

#ifdef BORLANDC 

// PC-specific includes 

# include . . 

#endif 



#ifdef Unix 

// UNIX-specific includes 

# include . . 

#endif 

Figure 10: Selective includes of a sample Borland C++ header file. 



behaves selectively for include files. Compiler checks the operating system and uses the 
appropriate include files. Since all the modules and objects have two parts which are 
interface and implementation, implementation part could have specific features to its 
environment. The User or programmer is not interested in that part. To port a software to 
another environment requires compiling & linking again. 

7. Project Management 

Designing and implementing systems consisting of tens of thousands, if not millions, 
of lines of code is quite different matter. The effort required to complete such a system 
is clearly beyond the intellectual physical capacity of one person. [Ref. 3: p.7] 
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Gathering more people into a single project creates other problems: 
Communication and coordination. 

FIGURE 1 1 on page 43 displays the resource allocation for 0-0 FATDS / FS in 
terms of time. The time which is spent for analysis and design is more than coding. This 
one of the characteristics of 0-0. Design decisions effect the future works. Reuse should 
be a project goal like any other [Ref. 16: p.44]. 



Resource^ 



Analysis Design Coding Testing 



Figure 11: Time allocation for development elements. 




a. Project Organization 



There are four types of alternative project development styles [Ref. 16: p.44]: 

• Rapid prototyping 

• Round-trip 

• The iterative style: Develops a series of solutions to a problem, each one close to 
satisfying the requirements. Each solutions is complete but its accuracy or 
acceptability improves with each pass. 

• The incremental style: Builds system functionality a little at a time. It differs from 
iterative development in that the results of each increment are not an entire solution, 
but part of it. This style has been advocated for some time for conventional projects. 
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Object-oriented development is best suited to the iterative or incremental 
style of development. Abstraction of the real world objects in 0-0 terms makes possible to 
work with objects or modules independently. Object can be put in action as soon as it 
possible whether they are completely ready, or not. This gives a chance for: 

* Early evaluation of objects which justifies the rest of the work. 

♦ Estimating the cost of the remaining job more realistically. 

• Allocating the resources equally for mid-term goals. 

For is research a model named model-based project development cycle , has 
been applied for FATDS/FS. It is both incremental and iterative. FIGURE 12 on page 44 
shows the object development algorithm with MBPDC. OOD sets the goals of each object. 
Since an object may not be fully functional at moment during the implementation-testing 
process, mid-term expectations should be planned for them (current goal(s)). 




Figure 12: Object development in MBPDC. 
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Conventional design methodologies have the problem of decomposing the 
problem domain in to functional sub units. Since their modules represent verbal actions, 
conventional languages are not good for iterative development cycle. 
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V. DATABASE MANAGEMENT SYSTEM (DBMS) SELECTION FOR FATDS 



A. INTRODUCTION 

FATDS has a great deal of data to manipulate. Data should be: 

• Kept in reliable environment(s) 

• Shared from other nodes of the system 

FATDS’s database system should provide: 

• A distributed environment: Supporting multiple workstations connected to a local or 
wide-area network, with one or more database servers providing transparent access to 
multiple data sources. 

• An advanced user interface: Provided by a graphics workstation or PC with the 
capability of integrating text, graphics, pictures, and possibly sound and video. 

Before implementing the database part of the project two questions should be 
answered; First, what will be the DBMS’s source? It could be: 

• Programming language’s own DBMS. 

• Application Developers’s own DBMS. 

• Commercially available DBMS. 

Second, what will be the database model for DBMS? It could be: 

• Object-oriented database model. 

• Other database models. 

• Composition of database models. 

B. CHOOSING A DBMS SOURCE 

1. Programming language’s own DBMS 

Borland C++ does not have a built-in DBMS like most of the other programming 
languages. If the programming language has provided a DBMS, then: 

• It would be completely object-oriented. 

• It may be easy to embed DBMS functions or objects into the source code. 

• It may not be satisfactory for the applications requirements, e.g., security, integrity, 
suitability to distributed databases and/or for large objects. 
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• There would still be problems about using existing databases (which have been created 
by other DBMSs. 

• It would have enforce to use the same language’s native DBMS format for other 
applications. 

2. Application Developers’s own DBMS 

Another option is to develop a DBMS which has been created specially for the 
project or general purpose. It is not commercially available. If it is task-oriented then it 
meet all the requirements of the project and acts well with the application code. It does not 
have to be implemented with application’s language, but to embed database system calls 
there should be third party communication programs in application’s language. 

One of the features of this implementation is that it is completely object-oriented 
like the first option. Since this choice under the control of the application developer, it can 
be maintained or modified according to requirements. 

The problem with these kind of DBMSs is maintenance. Its development should 
be included into the project, hence, this increases the project burden. 

3. Commercially available DBMS 

Commercially available DBMSs are also for general purpose, however there is a 
selection option according to the project requirements. These DBMSs are developed 
outside the project (FATDS) environment, so, developing a DBMS never be another task, 
but to use it. It is possible to use/create various databases other than the project’s. If it is a 
widely used commercial DBMS, it will possibly be used longer. 

Disadvantage with this choice is maintance. Only the DBMS vendor can provide 
necessary modifications on the application. 
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4. Choosing the DBMS Source for FATDS 



Using a commercially available DBMS is chosen for FATDS. If it does not 
specifically violates the requirements, “buying a product is generally cheaper then 
producing it”. 

One of the advantages of commercial DBMSs is that database can be created 
without using the host application. This provides to use the same database from other type 
of applications locally or via network. 

C. CHOOSING A DATABASE MODEL 
1. Database Model Options 

There are various data models. The major data models are hierarchical, network, 
relational and object data models. Each of the data model is not alternative of the other(s). 
There are advantages, disadvantages and suitable applications for each the data models. 

In hierarchical data model, data is organized in inverted tree structure and is 
accessed form the top the bottom in a series of nodes similar to branches in a tree. The 
inverted tree structure provides clearly defined and fixed path for accessing the data by 
traversing the branches of the tree. The rigidity of the structure has some disadvantages in 
that new access path, not defined at he outset, may complicated or even impossible to 
achieve. Modification of the database structure is a very complex task. 

The network data model traded off some of the high-access performance for 
flexibility in organizing and accessing the data. As in a hierarchical model, the data is 
organized in and inverted tree. The greater flexibility is achieved by allowing a node to be 
connected to more than one branch. Records are linked by predefined pointers. Equal or 
better performance, as compared to the hierarchial model, was achieved by maintaining 
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permanent pointers linking records. The complexity of the data structure made queries 
more complex and modification and ad hoc queries more complicated 

The relational data model promised a structure that met these new requirements. 
Structurally different from inverted trees of the hierarchical and network data models, data 
in the relational data model is stored in tables consisting of columns and rows. Links 
between data records are largely established as needed on an ad hoc basis. The rows of a 
table represent records and the columns within a table represent the fields in a record. 
Different types of records are stored in separate tables. Some frequently used connections 
between tables can predefined, while others can be established at the time of query. The 
data and their description are maintained separately, but changing data description is not 
simple. This model achieved the desired flexibility and ease of use, but at a cost. The 
relational data model requires a higher level of processing to establish connections and 
access data. Consequently, system requirements for processor and memory are higher to 
achieve the same level of overall performance. 



The Object data model differs itself from other models representing real-world 
data in intelligent objects which combines the abstraction and behavior of the real-world 
objects. Direct correspondence between real-world and database objects maintains 
integrity and identity of objects so they can be easily identified and operated upon [Ref. 13: 
p.442]. Objects have their own behaviors, this provides them to interact with other data 
models. Advantages of the object data model: [Ref. 13: p.444] 

• Extensibility: Object types and their methods can be modified as needed. Such changes 
are localized to the relevant object type and hence are much easier than in record- 
based system. 

• Behavioral constraints: Because of encapsulation, the behavior of each object type is 
predetermined by a fixed set of methods. Hence, database operations are constrained 
to be within these behavioral specifications. 

• Flexibility of type definition: The user is not limited to the modeling concepts of data 
model but can define many variations of data types, each with unique properties. 
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• Modeling power: The inheritance of both attributes and methods is very powerful tool 
for data modeling. In general, the abstractions of generalizations! specialization, 
identification, and aggregation are well supported in the current data models. 

Disadvantages of the object data model: 

• Lack of associations: The abstraction of association is not directly supported and is 
achieved indirectly by allowing interobject references. This is an inherent weakness of 
the 0-0 approach. 

• Behavioral rigidity: The predetermining and prespecifying all operations by a fixed set 
of method create this rigidity. 

• No high-level query language: There are no high-level query languages for current 
data models. 

2. Interfacing Objects with the Other Models 

Object-oriented databases provides to write and read objects to the disk, normally 
using static or dynamic link libraries with the code.The physical storage format on the disk 
is hidden from the application. The format can be flat files, relational files, hierarchical 
files, or any other type. 

The most primitive OODBMSs use a custom file format and enable you to only store 
objects on disk. These products offer little advantage.... Likewise, the manufacturers 
of these products require you to purchase their software and, occasionally, a run-time 
license for each product distributed. [Ref.20: p.5] 

A OODBM may either: 

• Store its objects using a format compatible with existing commercial database 
management systems such as Oracle, Sybase, dBase IV, Dr Paradox: Data consistency 
is ensured and all transactions are performed internally by the OODB. The 
disadvantages are technical difficulties and the relatively slow performance. 

• Exists in parallel with a commercial database management system that mirrors the data 
in the object-oriented database: It requires an update scheme to ensure that the data in 
both databases remains in synch. Accessing data in an object-oriented database is 
much faster -2 to 10 times faster- than in an relational database. 

3. Choosing a Data Model for FATDS 

There is no single data model which completely fits FATDS ’s database 
requirements. Object-oriented databases can interface with other data model. This provides 
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the opportunity of combining the advantages of different data models. For this research, 
interfacing objects with relational DBMS is selected. 

In relational DBMSs, the structured organization of data in tables and the 
capability of the database system to interpret each column of data serves well for 
applications involving pure numerical and textual data. Variable length data elements such 
as free-form text, images, and voice does not fit into the structure of relational databases. 
Relational database vendors created a new class of data type called Binary Large Objects 
(BLOBs). These data types can hold very large (and variable length) data and they are not 
interpreted by the database. This new feature provides relational DBMSs to support 
multimedia data management. 



Relational database model has advantages that the OODBM can not support: 
[Ref.22: p.68][Ref.26: p.33] 

« The relational schema is stored in the database catalog. 

» General-purpose query programs can use the catalog. 

• The SELECT, PROJECT, and JOIN operators can build new database views at run 
time. 

• The database is cross-compatible with other applications that use the same DBMS. 

• The data and their description are maintained separately. 

The object data model has advantages that the relational data model can not 
support [Ref.22: p.68][Ref. 18: p. 169]: 

• Variable length data member: It can support such applications as imaginary, 
multimedia, geographic data, weather. 

• Abstraction: The behavior of an object is described by a class definition that is created 
by data abstraction. By incorporating data abstractions at the level of the database, it 
is possible to make changes to the way a database class is implemented. 

• Class extensibility: In a relational database, the only parameterizable type is a 
relation, and the only operations possible on all relations are get _feld_value and 
set _feld_value. In the object data model, interface of each object is customized to that 

object. 

• Arrays permit repeating groups. 
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• Encapsulation: Encapsulation of data formats with methods bind data representation 
and behavior. 

• Polymorphism: Customizes the behavior of derived data types. 

• Integrity: Especially for large systems, the integrity of analysis, design and 
programming to map the real-world data into objects provides the simplicity to build 
the database system. This provides easy maintenance of the database system. 

• Reusability and adaptability: They are the two important features of object-oriented 
systems, which are accomplished using inheritance. 

• OODBMSs are faster: Because, relational databases pull information from a variety of 
tables into one result set, based on JOIN operation while OODBMSs make the same job 
by calling member functions. 

• Automatic type checking at the point of use: The object-oriented database performs 
type checking on the arguments to method calls. Thus, type errors are detected at the 
time of invocation rather than at the end of a transaction. 

• Schema evolution: Conventional data models do not support efficient mechanisms for 
schema evoluton. Object data model allows user-defined operations making the 
addition easier. Schema evolution includes changes to the defination inside a class and 
changes to the structure of the class lattice. A set of invariants and rules can be defined 
so that the schema will remain consistent as it evolves. 

D. DBMS FOR FATDS 

FATDS’s database is implemented in object-oriented fashion which interfaces a 
commercial DBMS, Paradox. Borland’s Paradox for Windows, version 1.0, is a relational 
DBMS. Paradox provides network support, password protection using encryption, binary 
large objects (BLOBs), multiple indexes, and composite indexes. 



To use Paradox table in the applications and embed into the C++ source code a third 
party Engine is need: Paradox Engine. The Paradox Engine, version 3.0, is and API 
containing more than 90 functions accessible from a C, C++, or Pascal program. The 
Engine provides to create database tables and indexes and to perform all database-related 
operations. The Paradox Engine is implemented as a DLL (for windows) that can be 
distributed royalty-free. The problem with the Engine is the DLL file is implemented in C, 
so it is not object-oriented. To keep the applications completely implemented in O-O, 
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another DLL file is created, which is in O-O. The design and implementation issues of 
FATDS’s database is discussed in the next chapter. 



The benefits or advantages of this choice: 

• Working with other data format files too: The application(s) may have to work with 
other data formats. FIGURE 13 on page 53 displays the object-interfaced data 




environment. Objects can be implemented to filter diverse database formats, hiding 
unnecessary details from the users and end-programmers. Only the database object are 
necessary to be updated according to the target database, not the application. This 
makes the modification easier. 

♦ Using a reliable DBMS: Instead of creating a DBMS which is normally a independent 
task, using a commercially developed (so testedO provides more reliable DBMS 

environment. 

• Faster database development: Data does not have be created or maintained by the 
mission-oriented applications. It should be created! maintained without running the 
application or creating a special program. Database design and implementation of 
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FATDS, including custom forms, can be created by Paradox for Windows, without 
using any user-created application. 

• Using the data with other applications: Other applications created independent from 
FATDS may use the same data. Regarding the hugeness of the project and time period 
of using the application, generally accepted data formats provides flexibility in use. 
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VI. OBJECT-ORIENTED DATABASE DESIGN OF FATDS 



A. INTRODUCTION 

The database system of FATDS is determined as object-oriented database system 
which incorporates a relational DBMS. OODBMS has a front-end role in this system and 
back-end could be any DBMS in any data model. Object structure of the system facilitates 
to work with heterogenous back-ends. Using various DBMSs as a back-end effects the 
design of the database. Back-end database could be: 

• Created independent from the front-end implementation. 

• Created simultaneously or incorporating with the front-end. 

Two of the situations may effect the object design differently. Creating the object- 
database as a front-end together with the back-end database may increase the reusability of 
the objects for later developments. For this research first option is followed to show: 

• How object-oriented database systems coexists with the existing databases. 

• The benefits of object-oriented database system interfacing with relational DBMSs. 

One of the benefits of the of OODBMSs is their implementation language. Non-O-O 
database system mostly have their own data languages which are not capable of complete 
computational power like programming languages. OODBMSs’ languages are complete 
programming languages as well. This facilitates to combine database development and 
program development together. 

Design methodology will follow the steps: 

• Identify the basis for the database requirements 

• Define the database’s functional and performance requirements 

• Conceptual design 

• Identify classes 

• Identify attributes and services (member functions) 

• Identify the relationship between classes 

• Database implementation 
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B. DATABASE REQUIREMENTS AND ANALYSIS OF FATDS 
I. The Role of Artillery 

The mission of field artillery (FA) is to destroy, neutralize, or suppress the enemy 
by cannon, rocket and missile fires and to assist in integrating fire support into combined 
arms operations. The main role of FA is to ease the achievement of commander’s objective 
with its fire power. The commander is a maneuver unit commander at any level. 

Targets could be anything on the battlefield: Enemy units, bridges, areas, roads, 
tanks, trenches, convoys, etc. Main point is that targets are not artillery’s, but the 
commander’s. So, all the target acquisition elements work under the maneuver 
commanders’ control. 

Since artillery normally does not have eye contact with the enemy targets, he 
relies on different sources for the target information; forward observers, air observers, 
radars, electronic counter measure units, higher headquarters, reconnaissance/intelligence 
units, commander himself, etc., almost everybody on the battlefield is source for target 
acquisition. A target could be immediate one or planned before. 

Depending on the organization of the FA there could be diverse weapons systems. 
Each weapon system has its own munitions and firing tablesr Firing table is a book which 
displays all numeric data about a specific gun & munition(s) combination. 

Although there are many, only the following major application functions are 
taken into account for database implementation: 

♦ Target management 

♦ Gun management 

♦ Firing table management (Table-F only) 

Other database areas are: 
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• Corrections management: It keeps and manipulates firing corrections for each gun and 
position pairs. 

• Fired mission history management: It is a derived database management. 

• Known points management: Radars, observation post positions, etc., are all known 

points. 

• Ammunition management: Amounts, type, caliber, lot are the fields to be managed. (It 
is designed but not implemented .) 

• Met messages management: It keeps up-to-date met messages. 

• Friendly forces management: Positions of friendly forces and other regions which are 
necessary for fire coordination, planning and security. 

2. Application Functional Requirements Overview 
a. T arget Management 

Each target is assigned a number like “AB2124”. First three digits represent 
a specific unit or element while the rest represent consecutively target numbers which are 
assigned to that unit/element. All the targets should be located at least with its coordinates, 
height and description. In addition to those: source (who located), locating accuracy, 
located time, category (there are 13 category groups and each target fits at least one of 
them), fired/notFired, priority, restrictions. 

Targets could be a point, a region (with a size), target groups (two or more 
targets with a different identification name), target series (more than one targets and/or 
target groups with a special name). Battalion FDC can form a target groups and series. A 
sample group name is B1C; letters represents who forms that group, the number digit in the 
middle is consecutive group number. A sample name for series of targets is CASEY, just a 
nick name. 



The decisions that comrise the decide function include: 

• What targets should be acquired and attacked. 

• Where and when the targets will likely be found and who can locate them. 

• How the targets should be attacked. 

• Whether target damage assesment is required. 

FDCs will be able to keep track of unlimited number of targets. 
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b. Gun management 



Each gun has a unique number within a battery. Together with battalion name 
and battery name each gun has a unique name. Guns can be organized in some batteries as 
platoons (four guns in a platoon and two platoon in a battery), if not, a battery has six guns. 
All the guns in battery are identical to each other. One of the guns in the battery is assigned 
as the main gun. 

In addition to name and each gun has position coordinates, model, maximum 
range, maximum left/right deflection, common orientation deflection, orientation 
deflection, firing table name. 

c. Firing Table Management 

Each gun has its own firing table. A firing table is composed of various tables: 

• Table-A: Line numbers of meteorological message. 

• Table-B: Complementary rang line number. 

• Table-C: Wind components. 

• Table-D: Temperature and density corrections. 

• Table-E: Propellant temperature. 

• Table-F: Basic data and correction factors. 

• Table-G: Supplementary data. 

• Table-H: Rotation-range. 

• Table-I: Rotation-azimuth. 

• Table-J: Fuze correction factors. 

Above tables are for specific shell type/model, fuze type/model and 
propelling charge/type. 

All the firing table data are constant. Any application should not be allowed 
to modify the tables. 
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C. DATABASE DESIGN OF FATDS 



1. Conceptual Design 

FIGURE 14 on page 60 and FIGURE 15 on page 61 display the ER diagrams for 
the Target, Gun and Table-F entities. The conceptual design is performed according to 
relational data model concepts. 



2. Identify Classes, Attributes and Services 

The classes which are formed as the front-end database classes are: 

• DBGunCls: Gun database management class. 

• DBTargetCls: Target database management class. 

• DBTable_F_Cls: Table-F management class. 

Tables 3, 4, 5 displays the data members and data functions of the database 

classes: 



TABLE 3: DATA MEMBERS WHICH ARE USED BY ALL THE DATABASE CLASSES. 



Name 


Access 


Description 


nFields 


Private 


Holds number of the fields in the database table. 


Names 


Private 


Holds the names of the all the table field names. 


Types 


Private 


Holds the type codes for each field of the database 
table. 
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Figure 15: ER diagram for FATDS/FS schema (Table F) 



61 



TABLE 4: MEMBER FUNCTION WHICH ARE USED BY ALL OF THE DATABASE CLASSES. 



Name 


Access 


Description 


RecordTobuf f er 


Protected 


Takes the field values from the database table from 
where the pointer is, and puts it to the buffer fields. 


ReadFirst 


Public 


Moves the database pointer to first record and 
reads the record into the record buffer. 


ReadLast 


Public 


Moves the database pointer to last record and 
reads the record into the record buffer. 


ReadNext 


Public 


Moves the database pointer to next record and 
reads the record into the record buffer. 


ReadPrev 


Public 


Moves the database pointer to previous record and 
reads the record into the record buffer. 


isTableEmpty 


Public 


Checks the table if it exist or empty and return 
TRUE if it is empty. 


isLast 


Public 


Checks the if the pointer is at the last record and 
returns TRUE if it is the last record. 


Reset 


Public 


Empties the record buffer and sets all the attributes 
to initial states. 
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TABLE 5: MEMBER FUNCTION WHICH ARE MOSTLY USED BY SOME OF THE DATABASE 

CLASSES. 



Name 


Access 


Description 


Buf f erToRecord 


Protected 


Takes the values from the buffer and puts them to 
the database table to where the pointer is. 


AddRecord 


Public 


Adds the record buffer to the database. (The record 
is appended if the database does not have a 
primary key that requires the database to be kept in 
sorted order.) 


UpdateRecord 


Public 


Copies the record buffer into the database as an 
update of the current record. 


DeleteRecord 


Public 


Deletes the current record. 


SearchByKey 


Public 


Searches the key field for a given field value. 


Set* 


Public 


Set the a field value into the buffer area. 


Get* 


Public 


Retrieves a field value from the buffer area. 


Any other specific 
member function(s) 







3. Database Implementation 

a. Paradox Database Tables Organization 

Table 6 displays the valid field types used in Paradox tables. 
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TABLE 6: PARADOX FIELD TYPES 



Type 


Storage Size 
in Bytes 


Description 


N 


8 


Floating point number with 15 significant digits in the 
range of 1 0 ’ 307 to 1 0 308 . 


s 


2 


Integer in the range of -32,767 to 32,767. 


$ 


8 


Same as floating point, but fixed at two digits of the 
decimal. 


D 


4 


The date. 


Annn 


1 to 255 


NULL-terminated string of length nnn, where nnn is 
less than 255. 


Mn 


n+10, where is 
in the range of 0 
to 240 


Unformated text BLOB, n represents BLOB-related 
header information, and the actual data is stored in a 
separate file pointed to by the file name stored in 
Paradox. 


Bn 


n+10, where is 
in the range of 0 
to 240 


Same as the preceding, but for unformated binary 
information. 


Fn 


n+10, where is 
in the range of 0 
to 240 


Same as the preceding, but for formated text. 


On 


n+10, where is 
in the range of 0 
to 240 


Same as the preceding, nut for Windows OLE objects. 


Gn 


n+10, where is 
in the range of 0 
to 240 


Same as the preceding, but for graphics data. 



b. Database File Organization 

The Paradox Engine provides the pxengwin.dll DLL file together with 
pxengine.h header file. Engine is implemented with C language, thus it is not object- 
oriented. The Engine with its more than 90 functions provides all the database file 
manipulations including: 

• Create, read, and write Paradox tables, record, and fields in DOS, Windows, and 
network environments. 
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• Create, read, and write Paradox BLOB fields. 

• Support explicit interactive Paradox and Paradox Applications Language (PAL) 
applications, as well as other Paradox Engine Applications. 

• Support other Paradox features such as password protection, encrypted table, date 
encoding, searching, and error handling. 

• Import data into Paradox tables through serial communications, such as when 
downloading form mainframes or from external devices that can not be reached from 
PAL. 

• Create stand-alone applications or applications that can be run with the PAL RUN 
command. 

FIGURE 16 on page 66 displays the file organization for the database 
development of FATDS. In order to create an object-oriented database engine, another 
DLL file is created namely paradox.dll. Paradox.dll is created with the files: 

• Paradox.*: Loads other header files required for others, support proper memory 
allocation if multiple applications are simultaneously using the paradox.dll. 

• Pdoxeng.*: Initialize the engine and shuts it down. 

• Pdoxrec.*: Performs single record operations in a database table such as putting data 
into the field or get data from the field. 

• Pdoxtab.*: It the engine is initialized it attempts to open a specific database table. If 
there is not that table, then it creates new one. 

Paradox.dll uses the Paradox Engine only. Database classes work with 
Paradox.dll. This hides all the Paradox implementations into the database objects. 
Application(s) is just aware of an object-oriented database implementation as a front-end. 
The database objects may interface any DBMS. 
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VII. CONCLUSION AND FUTURE WORKS ON FATDS 



A. SUMMARY AND CONCLUSIONS 

This thesis concentrated on the benefits of object-oriented approach over FATDS on 
sample programming implementations. The object-orientated approach mainly 
distinguishes itself form the other conventional ones especially in two phases: Design and 
maintenance. Object-oriented approach offers increased modeling power to represent the 
real world in a problem domain, a high level of abstraction, and the ability to inherit and 
refine object properties. Design takes the greatest portion of the software development 
cycle. Maintenance is not just an after-development-event , but a continuing phase with the 
design during the software’s life-time as well. 

The object-oriented development of FATDS is accomplished using a methodology 
namely model-based project development cycle. This methodology depends on the fact that 
nothing is perfect and a question that is “is this what you want?”. A development of a 
project should begin somehow, with a model of the product. The model is a prototype-like 
working element which gives an idea about the product but not necessarily a completely 
functional one. This model provides a chance to evaluation about the product and justifies 
the rest of the work. Evaluation causes modifications on the project. The inheritance, 
polymorphism and object abstraction features of object-oriented approaches facilitates the 
modification of the software and provides faster project development which satisfies the 
requirements than the conventional paradigms. 

By promoting code reusability the object-oriented paradigm reduces the cost and time 
required for software development. In order to exploit the reuse and portability of power of 
0-0 approach, design plays the key role. Object-oriented approach does not differentiate 
itself from other approaches without a good design. Thus, project members need to be 
experienced on OOA and OOD. 
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FATDS has the following features which make to work with object-oriented approach 
more beneficial than of the conventional ones: 

• Large-scale systems. 

♦ Modification on the software is frequently needed with new concepts, weapons, 
communication systems etc. 

• FATDS operators are short-termed trained on that system(s). 

♦ Incorporates a diverse large and distributed database. 

At the beginning of a object-oriented software development, the power of reuse may 
not put itself strong since there may not be much objects which are created before. As the 
development goes on, the speed of project development increases logarithmically. 

Advantages of object-oriented databases are that it offers the designer a high level of 
flexibility and power to implement arbitrarily complex and operations. 

Object-oriented database structures should resemble C++ or some other object- 
oriented language program structures for data in memory (that is, the equivalent of class 
instances or objects), thereby minimizing discontinues between programming and database 
operations and structures. A good OODBMS must be a full object-oriented database system 
that is designed to support large-scale object databases. It should reflect the object 
paradigm with object encapsulation and inheritance of both data and functions. [Ref. 1: 
p. 1 69] 

B. FUTURE WORK 

The programs, both the OChart and OFire are not completed and well-tested for 
complete functionality, so is the database of them. The followings will be done on the 
programs: 

• Firing with special munitions 

♦ Firing with met + MV. 

♦ Interfacing with outer devices. 

* Creating the other parts of the firing table databases and for other guns as well. 
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To continue on programming development increases the objects which are created, so 
does the reusability. This gives more reliable bases to compare object-oriented paradigm 
with the others. 
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APPENDIX A. (OFIRE HEADER FILES LISTINGS) 



Listing A.l: BURSTS.H header file 



// 

// bursts. h 

// 

// header file for the classes BurstsWndCls 
// SheafWndCls 



# if ndef BURSTS_H 

# define BURSTS_H 

//note that the following code is executed only 
//if this file has not been previously included 



#include "fire.h" 



#def ine ID_CONVERGED 
#def ine ID_PARALLEL 
#def ine ID_SPECIAL 
#def ine ID_OPEN 
#def ine ID_GUNS 



101 

102 

103 

104 

105 



_CLASSDEF ( Shea f WndC 1 s ) 
_CLASSDEF (BurstsWndCls ) 
//===================== 



// class BurstsWndCls 

// 

// Purpose : Displays the bursts on a canvas for' each gun and al lows 
// the user to modify them. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
All Rights Reserved 



// 

//== == = ==== = ========= = ============== 

class BurstsWndCls : public TWindow 



{ 

private : 



RECT 

PSheafWndCls 

PButton2Cls 

PButton2Cls 

PButton2Cls 

PButton2Cls 

HBITMAP 

HBITMAP 



WndRect ; 

Sheaf Wnd ; 
ButtonConverged; 
ButtonParallel ; 
ButtonSpecial ; 
ButtonOpen ; 
hBitmapl ; //north 
hBmpLe f t Arrow ; 



sign 
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public : 



PTListBox ListGuns; 



} ; 



BurstsWndCls ( PTWindowsObj ect AParent , 

LPSTR ATitle, 

int X, int Y, int dX, int dY) ; 



-BurstsWndCls 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 



() ; 

SetupWindow ( ) ; 

Paint (HDC PaintDC, 
ConvergedSheaf (RTMessage) 
ParallelSheaf (RTMessage) 
SpecialSheaf (RTMessage) 
OpenSheaf (RTMessage) 

Guns (RTMessage) 

DrawBorder (HDC hDC, int 
BOOL isUp) ; 



PAINTSTRUCT&) ; 
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[ID_FIRST 
[ ID_FIRST 
[ ID_FIRST 
[ID_FIRST 
[ ID_FIRST 
int yl , 



+ 

+ 

+ 

int 



ID_CONVERGED] ; 
I D_ PARALLEL ] ; 
ID_SPECIAL ] ; 
ID_OPEN] ; 
ID_GUNS] ; 
x2, int y2. 



virtual 

virtual 

virtual 

virtual 



void UpdateList ( ) ; 
void UpdateButtonArrow ( ) ; 
void UpdatelnfoArea ( ) ; 
void UpdateSheafWindow ( ) ; 



// = 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// = 



class 

Purpose 

Notes 



SheafWndCls 

Creates a canvas for BurstsWndCls as a child window, 
displays the bursts. 



Copyright: Copyright (c) 1993, Mustafa ESER 

All Rights Reserved 



class SheafWndCls : public TWindow 

{ 

private : 



RECT 

HCURSOR 

int 

int 

long 



WndRect ; 

hCursorTo; 

Cx; 

Cy ; 

ScaleFactor ; 



public : 



dY) 



SheafWndCls ( PTWindowsObj ect AParent , 

LPSTR ATitle, 

int X, int Y, int dX, int 
-SheafWndCls ( ) ; 
virtual LPSTR GetClassName ( ) ; 

void SetupWindow () ; 

Paint (HDC PaintDC, PAINTSTRUCT& ) ; 

WMLButtonDown (TMessage &Msg ) = [ WM_FIRST +WM_LBUTTONDOWN] 
WMSetCursor (TMessage Sc) =[WM_FIRST + WM_SETCURSOR] ; 



virtual 

virtual 

virtual 

virtual 



void 

void 

void 
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#endif BURSTS_H 



Listing A.2: BUTTON2.H header file 



// 

// button2.h 

// 

// header file for Button2Cls class 



# i f nde f BUTT0N2__H 

# define BUTT0N2_H 

//note that the following code is executed only 
//if this file has not been previously included 



#if def BORLANDC 

// PC-specific includes 

# include <owl.h> 

# include <button.h> 
#endif 



#ifdef Unix 

// UNIX-specific includes 
#endif 



_CLASSDEF ( But ton2Cls ) 
//==================: 

// class 

// 

// Purpose 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// Notes 

// 

// 

// Copyri 



Button2Cls 

Creates a custom button. It inherits all the behavior 
TButton class and adds the following features: 

>It has a constant background. 

>It may be instantiated with atmost two bitmap 
resource name, if it is intanctiated with two 
bitmaps, it displays the first one regularly and 
displays the second one when the button clicked. 
If it is instantiated with one bitmap only, then 
it displays that bitmap for all occassions. 

It may be instantiated with no bitmaps. 

>Bitmap is displayed on the right of button while 
the text is on the left . 

The size of bitmap file should be smaller than the 
button sizes. Otherwise the bitmap is clipped. 



// 



ght : Copyright (c) 1993, Mustafa ESER 
All Rights Reserved 
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class Button2Cls : public TButton 

{ 

private : 



char Text [80] ; 
RECT BRect; 
HBITMAP hBitmapl; 
HBITMAP hB it map 2 ; 



protected : 



virtual 

virtual 

virtual 

virtual 

virtual 

virtual 



void 

void 

void 

void 

void 

void 



ODADrawEntire ( DRAW ITEMS TRUCT 
ODAFocus (DRAWITEMSTRUCT _FAR 
ODASelect (DRAWITEMSTRUCT _FAR 
DrawFrame ( HDC hDC, RECT Rect, 



_FAR & Drawlnfo) 
& Drawlnfo) ; 

& Drawlnfo) ; 
BOOL Selected) ; 



WriteText (HDC hDC, 
PutBitmap (HDC hDC, 



LPSTR Text ) ; 

BOOL Pressed = FALSE) 



public : 



Button2Cls (PTWindowsObject 
int 
LPSTR 
LPSTR 
LPSTR 
int 
int 
int 
int 
BOOL 

PTModule 
~Button2Cls ( ) ; 

} ; 



AParent , 

An Id r 
AText , 

BitmaplName , 
Bitmap2Name , 

X, 

Y, 

W, 

H , 

IsDef ault , 
AModule = NULL) ; 



#endi f BUTTON2_H 



Listing A.3: COMMAND. H header file 



//★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★•A-*** 

// 

// command. h 

// 

// header file for CommandWndCls , 

// FireCommandsWndCls , 

// InfoWndCls, 

// SubFireCallWndCls , and 

// ChronoWndCls classes 

I j ******************************************************************* 



#ifndef COMMAND_H 

# define COMMAND_H 

//note that the following code is executed only 
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//if this file has not been previously included 



# include "fire.h" 



#def ine MAXVLINE 6 
#def ine MAXHLINE 8 
#def ine ID_SEND 100 
#def ine ID_FIRE 101 
#def ine ID_INFO 201 
#def ine I D_F I RECOMMANDS 301 
#def ine ID_SUBFIRECALL 401 

#def ine ID_CHRONO 501 
#def ine I D_WHENRE AD Y 502 
#def ine I D_ATMY COMMAND 503 
#def ine ID_ATTIME 504 
#def ine ID_AFTERTIME 505 



_CLASSDEF (CommandWndCls ) 
_CLASSDEF ( FireCommandsWndCls ) 
_CLASSDEF ( Inf oWndCls ) 
_CLASSDEF ( SubFireCallWndCls ) 
_CLASSDEF { ChronoWndC 1 s ) 
//=========================== 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// = 



class CommandWndCls 

Purpose : Hosts the other child windows. 

Notes : It has one more constructure which is encapsulated as 
protected. It is suppossed to be used only by its sub 
classes . 

Copyright: Copyright (c) 1993, Mustafa ESER 

All Rights Reserved 



class CommandWndCls : public TWindow 

{ 

private : 



RECT 

PF i r eCommandsWndC 1 s 

PInf oWndCls 

PSubFireCallWndCls 

PChr onoWndC 1 s 

PButton2Cls 

PButton2Cls 

PButton2Cls 

PBut ton2Cls 

PButton2Cls 

PButton2Cls 



WndRect ; 

FireCommandsWnd ; 
InfoWnd; 

SubFireCal lWnd ; 
ChronoWnd; 
ButtonSend; 
ButtonFire ; 
ButtonFireCommands ; 
Buttonlnf o ; 
ButtonSubFireCall ; 
ButtonChrono ; 



public : 



CommandWndC 1 s ( PTWindowsOb j ect AParent , 
LPSTR ATitle, 
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int X, 

int Y , 

int dX, 

int dY) ; 

-CommandWndCls ( ) ; 
virtual void SetupWindow () ; 
virtual void Paint (HDC PaintDC, 
virtual void Send (RTMessage) 
virtual void Fire ( RTMessage ) 
virtual void Fi reCommands (RTMessage) 
virtual void Info (RTMessage) 
virtual void SubFireCall (RTMessage) 



PAINTSTRUCT& ) ; 

= ( ID_FIRST + 
= ( ID_FIRST + 
[ ID_FIRST + 
[ ID_FIRST + 
[ ID_FIRST + 



ID_SEND] ; 
ID_FIRE] ; 

I D_F I RECOMMANDS ] 
ID_INFO] ; 

I D_SUBF I RECALL ] ; 



virtual void Act ivateChronometer ( long dT) ; 



protected : 



CommandWndCls ( PTWindowsObj ect AParent , 
LPSTR ATitle) ; 



} ; 



//=================================================================== 

// class Fi reCommands WndC Is 

// 

// Purpose : Display fire commands for each gun which is to fire. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//=================================================================== 

class FireCommandsWndCls : public TWindow 

{ 

private : 

RECT WndRect; 

int VLine [MAXVLINE-1 ] ; / /x coordinates of vertical 1 ines /borders 
int HLine [MAXHLINE+1 ] ; / /y coordiantes of horizantal 1 ines/borders 

public: 



}; 



PTWindowsObj ect 


AParent , 


LPSTR 


ATitle, 


int 


X, 


int 


Y, 


int 


dX, 


int 


dY) ; 



-FireCommandsWndCls ( ) ; 
virtual void SetupWindow () ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCT& ) 



// class InfoWndCls 

// 

// Purpose : Displays fire call, fire order and message to observer 
// messages after they have been set. 
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// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//=============================================== 

class InfoWndCls : public TWindow 

{ 

private : 

RECT WndRect ; 

public : 

InfoWndCls ( PTWindowsOb j ect AParent , 

LPSTR ATitle, 

int X, int Y, int dX, int dY) ; 
-InfoWndCls ( ) ; 
virtual void SetupWindow ( ) ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCT& ) ; 

} ; 



//================================================= 

// class SubFireCallWndCls 

// 

// Purpose : Displays subsequent fire calls. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//================================================= 

class SubFireCallWndCls : public TWindow 

{ 

private : 

RECT WndRect; 

public : 

SubFireCallWndCls ( PTWindowsOb j ect AParent, 

LPSTR ATitle, 

int X, int Y, int dX, int dY) ; 
-SubFireCallWndCls ( ) ; 
virtual void SetupWindow () ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCT& ) ; 

) ; 



// class 
// 

// Purpose 
// 

// 

// 

// Notes 

// 



ChronoWndCls 

Displays a digital chronometer for seting the firing 
time. It also instantiates the firing if it is a timed 
firing . 

Windows 3.1 allows only 16 clocks to work simultaneously, 
each OFIRE program executes one already. 
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// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================ 

class ChronoWndCls : public TWindow 

{ 

private : 



PTBRadioButton RadioWhenReady ; 
PTBRadioButton Radio At My Command; 
PTBRadioButton RadioAtTime ; 
PTBRadioButton RadioAf terTime ; 
RECT WndRect ; 

WORD wTimer; 

WORD wE lapse; 

long dTime; 

int Hour; 

int Minute; 

int Second; 

public : 



} ; 



ChronoWndCls ( PTWindowsObj ect AParent , 



LPSTR 


ATitle 


int 


X, 


int 


Y, 


int 


dX, 


int 


dY) ; 


-ChronoWndCls ( ) ; 





virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 



SetupWindow ( ) ; 

Paint (HDC PaintDC, 
WMTimer (RTMessage) = 

WhenReady ( RTMessage ) = 

At My Command (RTMessage) = 
AtTime ( RTMessage ) - 

Af terTime ( RTMessage) = 
StartCountDown ( long dT) ; 



PAINTSTRUCT& ) ; 

= [WM_FIRST + 
ID_FIRST + 
ID_FIRST + 
ID_FIRST + 
ID FIRST + 



WM_TIMER] ; 

I D_WHENRE ADY ] ; 

I D_ATMY COMMAND] ; 
ID_ATTIME] ; 
ID_AFTERTIME] ; 



# end if COMMAND_H 



Listing A.4: FIRE.H header file 



// 

// fire.h 

// 

// header file for dialog class declerations which are: 
/ / FireCallDlgCls , 

// PolarWndCls, 

// ShiftWndCls, 

// GridWndCls , 

// SuppressionWndCls , 

// FireOrderDlgCls , 

// MTODlgCls , 

// SubFireCal lDlgCls , 
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// TOTAtTimeDlgCls, 

// TOTAf terTimeDlgCls . 



#if ndef FIRE H 

# define FIRE H 

#if def BORLANDC 



// PC-speci 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

# include 
#endif 



fic includes 
cowl . h> 
cedit . h> 
clistbox . h> 
ccombobox . h> 
cscrollba .h> 
cdialog . h> 
cbwcc . h> 
cbutton . h> 
cstr ing . h> 
cbchkbox . h> 
cbradio . h> 



#ifdef Unix 

// UNIX-speci f ic includes 
#endif 



#include "button2.h" 
#include "dbtarget.h" 
# include "dbgun . h" 



//firecall dialog 
#def ine I D_F I REORDER 


106 


#def ine 


ID_VIEW 


105 


#def ine 


ID_FROM 


107 


#def ine 


I D_M I SS I ONTY PE 


108 


#def ine 


ID_SIZE 


109 


#def ine 


ID_POLAR 


110 


#def ine 


ID_SHIFT 


111 


#def ine 


ID_GRID 


112 


#def ine 


ID_SUPPRESSION 


113 


#def ine 


ID_DESCRI PTION 


129 


#def ine 


I D_TARGETNO 


111 


#def ine 


I D_D I RECTI ON 


101 


#def ine 


ID_DISTANCE 


102 


#def ine 


ID_UPDOWN 


103 


#def ine 


ID_SHIFTFROM 


104 


#def ine 


ID_RIGHTLEFT 


105 


#def ine 


ID__ADDDROP 


106 


#def ine 


ID_ZONE 


107 


#def ine 


ID_EAST 


108 



109 

110 



#def ine ID_NORTH 
#def ine ID_HEIGHT 

//mto dialog 
#def ine ID_MTO 101 

#def ine ID_PROCESS 110 

#def ine I D_UN I TTO FIRE 107 

#def ine ID_GUNLIST 119 

#def ine I D_AD JU ST I NGELEMENT 108 



//sub-fire call dialog 
#def ine ID_DEVIATION 


101 


#def ine 


ID_DI STANCE 


102 


#def ine 


ID_HOB 


103 


#def ine 


ID_HOUR 


701 


#def ine 


ID_MINUTE 


702 


#def ine 


ID_SECOND 


703 



CLASSDEF ( PolarWndCls ) 
CLASSDEF ( Sh i f t WndC 1 s ) 
CLASSDEF ( Gr idWndC 1 s ) 
CLASSDEF ( Suppress ionWndCls) 



class 




FireCal lDlgCls 


Purpose 


Demonstrates 


FireCall dialog box 


Notes : 


It work with 
files are on 


Paradox Engine, make sure related *.dll 
path . 


Copyright : 


Copyright (c) 1993 , Mustafa ESER 
All Rights Reserved 



class FireCal lDlgCls : public TDialog 



{ 

private : 



RECT cWnd; 
PPolarWndCls 
PShif tWndCls 
PGr idWndC Is 
PSuppress ionWndCls 
PTComboBox 
PTComboBox 
PTComboBox 



PolarWnd ; 

Shif tWnd; 

Gr idWnd; 

Suppr ess ionWnd ; 
ComboFrom; 
ComboType ; 
ComboS ize; 



//source of fire call 

//type of mission 

//size of element for effect 



public : 

FireCal lDlgCls ( PTWindowsObj ect AParent , 

LPSTR AName) ; 

-FireCallDlgCls ( ) ; 
virtual void SetupWindow ( ) ; 

virtual void RadioPolar (RTMessage ) =[ID_FIRST + 

virtual void RadioShi ft ( RTMessage ) =[ID_FIRST + 

virtual void RadioGr id ( RTMessage ) =[ID_FIRST + 

virtual void RadioSuppression ( RTMessage ) = [ ID_FIRST + 

virtual void But tonOrder (RTMessage) = [ID_FIRST + 

virtual void ButtonView (RTMessage ) = [ID_FIRST + 

virtual void UpdateFrom ( ) ; 



I D_ POLAR] ; 
ID_SHIFT] ; 
ID_GRID] ; 
ID_SUPPRESSION] 
I D_F I REORDER] ; 
ID_VIEW] ; 
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virtual void UpdateSize ( ) ; 
virtual void UpdateType ( ) ; 
virtual void UpdateTargetDatabase ( ) ; 



// = 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// = 



class 



Purpose 



Notes 



PolarWndCls 

Child window for FireCallDlgCls . 
Displays polar location type controls. 



Copyright: Copyright (c) 1993, Mustafa 

All Rights Reserved 



ESER 



class PolarWndCls : public TWindow 



{ 

private : 



RECT WndRect; 

PTEdit Edit Direct ion ; 
PTEdit EditDistance ; 
PTEdit EditUpDown ; 



public : 



PolarWndCls ( PTWindowsOb j ect AParent , 

LPSTR ATitle, 

int , int , int , int ) ; 
-PolarWndCls ( ) ; 
virtual void SetupWindow ( ) ; 

virtual void Paint (HDC hDC, PAINTSTRUCT Sc) ; 
virtual void SetLocValues ( ) ; 



Shif tWndCls 



//==============: 

// class 

// 

// Purpose : Child window for FireCallDlgCls. 

// Displays shift location type controls. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//======== ======= = ===== == =========================== : 

class ShiftWndCls 

( 

private : 



public TWindow 



RECT 

PTComboBox 

PTEdit 

PTEdit 

PTEdit 



WndRect ; 
ComboFrom; 

Ed it Direct ion ; 
EditRightLef t ; 
EditAddDrop ; 
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PTEdit EditUpDown; 

PDBTargetCls DBTargets ; 



public : 

Shif tWndCls ( PTWindowsObj ect AParent , 

LPSTR ATitle, 

int, int, int, int); 

-Shif tWndCls ( ) ; 

virtual void SetupWindow () ; 

virtual void Paint (HDC hDC, PAINTSTRUCT Sc); 

virtual void TargetNo ( RTMessage ) = [ID_FIRST + ID_SHIFTFROM] ; 
virtual void SetLocValues () ; 
virtual BOOL UpdateComboFrom ( ) ; 



GridWndCls 

Child window for FireCal lDlgCls . 
Displays grid location type controls. 



//========= 

// class 

// 

// Purpose 

// 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//============================================ 



class GridWndCls : public TWindow 



{ 

private : 



RECT WndRect; 

PTEdit EditZone; 
PTEdit EditEast; 
PTEdit EditNorth; 
PTEdit Edit Altitude ; 
PTEdit EditDirect ion ; 



public : 

GridWndCls ( PTWindowsObj ect AParent, 

LPSTR ATitle, 

int, int, int, int);* 

-GridWndCls ( ) ; 

virtual void SetupWindow () ; 

virtual void Paint (HDC hDC, PAINTSTRUCT Sc); 
virtual void SetLocValues (); 



//: 


II 

II 

II 

II 

II 

II 

II 

II 


// 


class 


// 




// 


Purpose 


// 




// 




// 


Notes 


// 





Suppress ionWndC Is 

Child window for FireCallDlgCls . 

Displays suppression location type controls. 
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// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//============================================ 

class SuppressionWndCls : public TWindow 

( 

private : 

RECT 
char 
long 
long 
long 

PTComboBox 
PTEdit 

PDBTargetCls 
char 

public : 

SuppressionWndCls ( PTWindowsObj ect AParent, 

LPSTR ATitle, 

int, int, int, int); 
-SuppressionWndCls ( ) ; 



WndRect ; 

Zone [ 5 ] ; 

East ; 

North; 

Height ; 

ComboTargetNo ; 
Edit Dir ect ion ; 
DBTargets ; 
Description [80 ] ; 



} ; 



virtual void 
virtual void 
virtual void 
virtual void 
virtual BOOL 
virtual char 



SetupWindow ( ) ; 

Paint (HDC hDC, PAINTSTRUCT Sc); 

TargetNo (RTMessage ) = [ID_FIRST + ID_TARGETNO] ; 
SetLocValues ( ) ; 

UpdateComboTargetNo ( ) ; 

*GetTargetDescript ion ( ) ; 



FireOrderDlgCls 

Demonstrates FireOrder dialog box 



//========= 

// class 

// 

// Purpose 

// 

// Notes : It work with Paradox Engine, make sure related *.dll 

// files are on path. 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

// = zzzz === == ====================================================== : 

class FireOrderDlgCls : public TDialog 

{ 

private : 



int 

int 

char 

long 

long 

long 

PTComboBox 

PTListBox 

PTButton 

PDBGunCls 



MainGun ; 

GunNo[8] ; 

Zone [8] [3] ; 

East [ 8 ] ; 

North [8] ; 

Height [ 8 ] ; 
ComboUnitToFire ; 
ListGuns ; 

ButtonAdjust ingElement ; 
DBGuns ; 



public : 
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} ; 



FireOrderDlgCls ( PTWindowsObj ect AParent , 
LPSTR AName) ; 



-FireOrderDlgCls ( ) ; 

virtual void SetupWindow () ; 

virtual void MTO ( RTMessage ) 

virtual void ProcessForFire (RTMessage) 

virtual void UnitToFire (RTMessage) 

virtual void Adjust ingElement (RTMessage) 



virtual BOOL 
virtual BOOL 
virtual void 



UpdateComboUnitToFire ( ) ; 
UpdateListGuns ( ) ; 

Col lectData ( ) ; 



= [ ID_FIRST + I D_MTO ] ; 
=[ID_FIRST + ID_PROCESS] ; 

= [ ID_FIRST + I D_UN I TTOF I RE ] 
=[ID_FIRST + 

I D_AD JUST INGELEMENT] ; 



// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 



class 

Purpose 

Notes 



Copyright 



MTODlgCls 

Demonstrates message to observer dialog box 

It work with Paradox Engine, make sure related 
files are on path. 

Copyright (c) 1993, Mustafa ESER 
All Rights Reserved 



class MTODlgCls : public TDialog 

{ 



public : 



* 



.dll 



MTODlgCls ( PTWindowsObj ect AParent, 

LPSTR AName) ; 

-MTODlgCls ( ) ; 

virtual void SetupWindow ( ) 

U 

virtual void Ok ( RTMessage ) = [ID_FIRST 4- IDOK] ; 

virtual void Cancel ( RTMessage ) = [ID_FIRST 4- IDCANCEL] ; 



//=========================== 

// class 

// 

// Purpose : Demonstrates subfire call dialog box 

// 

// Notes : It work with Paradox Engine, make sure related *.dll 
// files are on path. 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//================================================================= 

class SubFireCallDlgCls : public TDialog 

{ 

private : 



SubFireCallDlgCls 



PTEdit EditDeviat ion ; 

PTEdit EditDistance ; 
PTEdit EditHOB; 
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PTButton ButtonProcess; 



public : 



} ; 



SubFireCallDlgCls ( PTWindowsObj ect AParent , 

LPSTR AName) ; 



-SubFireCallDlgCls ( ) ; 
virtual void Process (RTMessage) 
virtual void Cancel ( RTMessage ) 
virtual void Help (RTMessage ) 



[ ID_FIRST 
[ ID_FIRST 
[ID_FIRST 



+ 

+ 

+ 



ID_PROCESS ] ; 
IDCANCEL] ; 
IDHELP] ; 



// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 



class 

Purpose 

Notes 

Copyright 



TOTAtTimeDlgCls 

Demonstrates (time on target) At Time dialog box 

It work with Paradox Engine, make sure related *.dll 
files are on path. 

Copyright (c) 1993, Mustafa ESER 
All Rights Reserved 



class TOTAtTimeDlgCls : public TDialog 

{ 

private : 



PTEdit EditHour; 
PTEdit EditMinute; 
PTEdit EditSecond; 



public : 



} ; 



TOTAtTimeDlgCls ( PTWindowsObj ect 
LPSTR 

-TOTAtTimeDlgCls ( ) ; 
virtual void SetupWindow ( ) ; 
virtual void Ok (RTMessage ) 
virtual void Cancel (RTMessage) 
virtual void Help (RTMessage ) 



AParent , 
AName) ; 



= [ ID__FIRST 
= [ ID_FIRST 
= [ ID_FIRST 



+ IDOK] ; 

+ IDCANCEL] ; 
+' IDHELP] ; 



TOTAf terTimeDlgCls 



//========z=================: 

// class 

// 

// Purpose : Demonstrates (time on target) After Time dialog box 

// 

// Notes : It work with Paradox Engine, make sure related *.dll 
// files are on path. 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

class TOTAf terTimeDlgCls : public TDialog 



{ 

private : 
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PTEdit EditHour; 
PTEdit EditMinute ; 
PTEdit Edit Second; 



public : 



TOTAf terTimeDlgCls ( PTWindowsObj ect AParent, LPSTR AName) ; 
-TOTAf terTimeDlgCls ( ) ; 



virtual void SetupWindow ( ) ; 

virtual void Ok ( RTMessage ) = [ID_FIRST 
virtual void Cancel ( RTMessage ) = [ID_FIRST 
virtual void Help ( RTMessage ) = [ID_FIRST 



IDOK] ; 
IDCANCEL] ; 
IDHELP ] ; 



#endif FIRE H 



Listing A.5: GLOBALS.H header file 



j / ★★★★★*★★★★★★★★★★★★★*★★★★★★★★★★★*★★★★★★★★★★★★★★★★★★★★★★★★★*★★★★*■★*★★ 

// 

// globals.h 

// 

// header file for global variables, objects and 
// Computat ionCls 



# i f nde f GLOBALS H 

# define GLOBALS H 



#include <string.h> 
#include "dbtbl_f.h" 



#def ine SUCCESS 1 
#def ine FAIL 0 



enum MissionType {mADJUSTFIRE, 

mFIREFOREFFECT, 
mSUP PRES SION, 
mIMMEDIATESUP PRESS ION, 
mIMMEDIATESMOKE) ; 



enum LocationType {POLAR, 

SHIFT, 

GRID, 

SUPPRESSION} ; 

enum Sheaf Type {CONVERGED, 

PARALLEL, 
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SPECIAL, 
OPEN} ; 



enum TimingType {WHENREADY, 

ATMY C OMMAND , 
ATTIME, 
AFTERTIME} ; 



//================================================ 

//struct Gun 

// 

// Purpose : Holds information for a gun 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//================================================ 

struct Gun 

{ 

int GunNo; 

//gun location 
char Zone [ 5 ] ; 

double East; 
double North; 
double Height; 

//firing command elements 
double Timing; 
double Deflection; 
double Elevation; 
double Quadrant; 

//target-hit info 
char Hi t Zone [ 5 ] ; 

double HitEast; 
double HitNorth; 
double HitHeight; 
double HitRange; 

double HitDef lection; //chart deflection 
double HitAzimuth; //gun-hit point azimuth * 

//gun general info 
double CommonOr ientat ion ; 



/ /_CLASSDEF (ComputationCls ) 

//========= ========================================================== 

// class ComputationCls 

// 

// Purpose : Makes all the computations for a gun battery fire direction 

// 

// Notes : It works with Paradox Engine, so necessary *.dll files 
// should be on path. 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

All Rights Reserved 



86 



class Computat ionCls 

{ 

private : 



WStr 

WStr 



Fir ingTableName ; 
FiringCharge ; 



PDBTab 1 e_F_C 1 s DBTable_F ; 



public : 



char 

char 

char 

char 

char 



Bat t eryName [ 3 ] ; 
CallLine [ 4 ] [80] ; 
OrderLine [ 80 ] ; 
MTOLine [80] ; 
SubCallLine [ 50 ] ; 



//observer information 
char ObserverNarae [ 1 0 ] ; 
char ObserverZone [ 1 0 ] ; 
double ObserverEast ; 
double ObserverNorth; 
double ObserverHeight ; 
double OTDi recti on; 

//target location before adjustment 
char IniTargetZone [ 3 ] ; 
double IniTargetEast ; 
double IniTargetNorth ; 
double IniTargetHeight ; 

double IniTargetRange ; //for main gun 

double IniTargetDef lection; //for main gun 

//target location after adjustment 

char CurrTarget Zone [ 3 ] ; 

double CurrTargetEast ; 

double CurrTargetNorth ; 

double CurrTargetHeight ; 

//target location settings 

// 

//polar 

double PolarDistance ; 
double PolarUpDown; 

// 

//grid 

char GridZone[3]; 
double GridEast; 
double GridNorth; 
double GridHeight; 

// 

//shift 

char Shif tFrom [ 10 ] ; 

char Shif tZone [ 10 ] ; 

double ShiftEast; 
double ShiftNorth; 
double ShiftHeight; 
double Shif tRightLef t ; 
double Shif t AddDrop ; 
double ShiftUpDown; 

// 

/ /suppression 

char SuppTargetNo [ 10 ] ; 
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char Descript ion [ 128 ] ; 

char Category [ 80 ] ; 

//fire command settings 
int NoOf Piece sToFol low; 



//current values 

char CurrFrom [ 10 ] ; 

char CurrMissionType [ 50 ] ; 

char CurrSize[10] ; 

LocationType CurrLocat ionType ; 

Sheaf Type CurrSheaf; 

//gun parameters 
Gun Guns [8] ; 

int MainGun; 

double AzimuthOf Fire ; 



//gun - ammo 

double BurstDiameter ; 

//fire commands buffers 
int FiredNo; 



Computat ionCls ( ) ; 

-Computat ionCls ( ) ; 

virtual void ComputeHi tCoors ( ) ; 

virtual void ComputeChartValues ( ) ; 

virtual void ComputeRangeAzimuth (double xl, 

double yl, 
double x2, 
double y2, 
double ScRange, 
double ScAzimuth) 

virtual void ComputeCoordinate ( double xl, 

double yl/ 
double Range, 
double Azimuth, 
double &x2 , 
double Scy2 ) ; # 

void SetFir ingTableName (WStr FTName) ; 

WStr GetFir ingCharge ( ) ; 

BOOL ComputeFir ingCharge ( ) ; 

BOOL ComputeElevat ions ( ) ; 

BOOL ComputeFiringValues ( ) ; 



void Reset ( ) 



#endi f GLOBALS H 



Listing A.6: REPORT.H header file 



// 
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report . h 



// 

// 

// header file for the classes ReportWndCls , 
// TextWndCls 



#i f ndef REPORT_H 

# define REPORT_H 

// Note the following code is only executed if 
// this file has not been previously included 



#include "fire.h" 



#def ine ID_PRINT 101 



_CLASSDEF (ReportWndCls ) 

_CLASSDEF ( TextWndC 1 s ) 

//================================================================= 

// class ReportWndCls 

// 

// Purpose : Hosts a canvas window which displays the firig report 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//================================================================= 

class ReportWndCls : public TWindow 

( 

private : 



RECT WndRect ; 

PTextWndCls TextWnd; 
PButton2Cls ButtonPrint; 

public : 



ReportWndCls ( PTWindowsObj ect 


AParent , 


LPSTR 


ATitle, 


int 


X, 


int 


Y, 


int 


dX, 


int 

-ReportWndCls ( ) ; 


dY) ; 



virtual void SetupWindow ( ) ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCT& ) ; 
virtual void Print (RTMessage) = [ID_FIRST + ID_PRINT] ; 

} ; 
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TextWndCls 



//====== 

// class 

// 

// Purpose : Serves as a canvas to display the firing report 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
ll All Rights Reserved 

//=========================================================== 

class TextWndCls : public TWindow 

{ 

private : 



RECT 



WndRect ; 



public : 

TextWndCls ( PTWindowsObj ect 
LPSTR 
int 
int 
int 
int 

-TextWndCls ( ) ; 

virtual void SetupWindow ( ) ; 

virtual void Paint (HDC PaintDC, 

} ; 



AParent , 
ATitle, 

X, 

Y, 
dX, 
dY) ; 



PAINTSTRUCT& ) 



#endif REPORT_H 



Listing A.7: SELECT.H header file 



// 

// select. h 

// 

// header file for the class SelectionWndCls 



# if ndef SELECT_H 

# define SELECT_H 

If Note the following code is only executed if 
// this file has not been previously included 



# include 
#include 
#include 
# include 



fire .h" 
command. h 
bursts . h" 
report .h" 
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#def ine ID_EXIT 101 
#def ine ID_HELP 102 



//from fire.cpp 
extern PCommandWndCls 
extern PBurstsWndCls 
extern PReportWndCls 



CommandWnd; 
BurstsWnd; 
ReportWnd ; 



_CLASSDEF (Select ionWndCls ) 

//=================================================================== 

// class Select ionWndCls 

// 

// Purpose : Displays notebook tab-stops to select different windows. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//=================================================================== 

class Select ionWndCls : public TWindow 

{ 

private : 



PTWindowsObj ect MainWnd; 



RECT 

POINT 

short 

PButton2Cls 

PButton2Cls 



WndRect ; 
IndexTab [ 3 ] [ 4 ] 
CurrlndexTab; 
ButtonExit ; 
ButtonHelp ; 



public : 



} ; 



Select ionWndCls ( PTWindowsObj ect 


AParent , 




LPSTR 


ATitle, 




int 


X, 




int 


Y, 




int 


dX, 




int 


dY) ; 




-Select ionWndCls ( ) ; 
virtual void SetupWindow ( ) ; 
virtual void Paint (HDC PaintDC, 


PAINTSTRUCT& ) ; 




virtual void WMLButtonDown (TMes 


sage &) = [WM_FIRST + 


WM_LBUTT0ND0WN ] 


virtual void Exit (RTMessage) 


= [ ID_FIRST + 


ID_EXIT] ; 


virtual void Help (RTMessage) 


= [ ID_FIRST + 


ID_HELP] ; 



#endif 
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APPENDIX B. (OCHART HEADER FILES LISTINGS) 



Listing B.l: ABSLIST.H header file 



j /**************************************★***************************★ 

// 

// abslist.h 

// 

// header file for the class genAbst ractList 



# if ndef _ABSLIST_H 
# define _ABSLIST_H 

//note that the following code is executed only 
//if this file has not been previously included 

#define ALLOCATE_ERROR "Dynamic allocation error" 

enum boolean { false, true }; 
typedef char st ring80 [ 81 ] ; 



// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 



template class genAbstractList 

Purpose : implements an abstract class of linked lists with 

the following operations and features: 

> nodes with duplicate keys can be allowed. 

> insert new node. 

> search for a node with a specific* occurrence 
of a key. 

> delete a node with a specific occurrence of a key. 

> traverse the nodes of the lists, 
the user to modify them. 

Notes : 

Copyright: Copyright (c) 1993, Mustafa ESER 

All Rights Reserved 



templatecclass T> 
class genAbstractList 
{ 

protected : 



unsigned 


listSize; 


n 


boolean 


overwrite ; 


n 


boolean 


hasDuplicate ; 


n 


str ing80 


errorMessage ; 


n 



number of nodes 
overwrite data flag 
duplicate-key flag 
error message 
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public : 

//state query methods 
boolean isEmpty() 

( 

return (listSize == 0) ? true : false; 

} 



unsigned getListSi ze ( ) 

{ 

return listSize; 

} 



char* getErrorMessage ( ) 

{ 

string80 s; 

strcpyfs, errorMessage) ; 
errorMessage [ 0 ] = '\0'; 

return s; 

} 



//object manipulation methods 
genAbstractList ( ) 

{} 



virtual boolean insert (T&) 

{ 

return false; 

} 



virtual boolean remove (T&, unsigned occur = 1)# 

{ 

return false; 

} 



virtual boolean search (T&, unsigned occur = 1) 

{ 

return false; 

} 



virtual boolean visi tFirstNode (T&) 

{ 

return false; 

} 
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virtual boolean visitNextNode (T&) 

( 

return false; 

} 



virtual void clear () 

{} 



#endi f _ABSLIST_H 



Listing B.2: CHART.H header file 



J j-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k 


II 


II 


chart . h 


t l 

II header 


file the classes Gr idSetupDlgCls 


// 


TargetSetupDlgCls 


// 


GunSetupDlgCls 


// 


NewEntryDlgCls 


// 


NewFromEntryDlgCls 


// 


GunlnputDlgCls 


// 


Target Input DlgC Is 


// 


Targe tDBDlgC Is 


// 


GunDBDlgCls 


j J-k-k-k-k-k-k-k * 





#if ndef CHART_H 

# define CHART_H 

//note that the following code is executed only 
//if this file has not been previously included 



#include 
#include 
#include 
# include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
# include 



<owl .h> 

<edit . h> 

< listbox . h> 
<combobox .h> 
<dialog . h> 
<bwcc .h> 
cbutton . h> 
<string .h> 
<stat ic . h> 
<scrollba . h> 
<bchkbox . h> 
<bradio . h> 



#include "defines. h" 
#include "globals.h" 
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# include "targetdb.h 
# include "gundb.h" 



//============================================ 

// class GridSetupDlgCls 

// 

// Purpose : Displays grid setup dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================ 

class GridSetupDlgCls : public TDialog 

{ 

private : 



PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTComboBox 

PTComboBox 

PTCheckBox 

PTCheckBox 



Edit Zone ; 

Edi tLef t ; 
EditRight ; 
EditBottom; 
EditTop; 
ComboDistance ; 
ComboScale ; 
CheckShowGr id ; 
CheckShowNor th ; 



public : 



GridSetupDlgCls ( PTWindowsObj ect 
-GridSetupDlgCls ( ) ; 
virtual void SetupWindow ( ) ; 
virtual void Ok ( RTMessage ) 
virtual void Cancel (RTMessage ) 
virtual void Help (RTMessage ) 



AParent, LPSTR AName) ; 



= [ID_FIRST + IDOK] ; 

= [ID_FIRST + IDCANCEL] ; 

= [ID_FIRST + IDHELP] ; 



//===== ===== = ====== = == = ========= , ================t========= 

// class TargetSetupDlgCls 

// 

// Purpose : Displays target setup dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

// = = = ==== ================================================== 

class TargetSetupDlgCls : public TDialog 

{ 

private : 

PTCheckBox CheckShowTarget s ; 
public : 

TargetSetupDlgCls ( PTWindowsObj ect AParent , LPSTR AName); 
-TargetSetupDlgCls ( ) ; 
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virtual void SetupWindow () ; 
virtual void Ok ( RTMessage ) 
virtual void Cancel ( RTMessage ) 
virtual void Help ( RTMessage ) 



[ ID_FIRST + IDOK] ; 
[ID_FIRST + IDCANCEL]; 
[ID_FIRST + IDHELP] ; 



} ; 



//============================================ 

// class GunSetupDlgCls 

// 

// Purpose : Displays gun setup dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//======================================== 

class GunSetupDlgCls : public TDialog 

( 

private : 

PTComboBox ComboScale; 

PTCheckBox CheckShowCover ings ; 

public : 

GunSetupDlgCls ( PTWindowsObj ect AParent , 
-GunSetupDlgCls ( ) ; 
virtual void SetupWindow () ; 

virtual void Ok ( RTMessage ) = 

virtual void Cancel (RTMessage) = 

virtual void Help ( RTMessage ) = 

} ; 



LPSTR AName) ; 



[ ID_FIRST + IDOK] ; 

[ ID_FIRST + IDCANCEL]; 
[ID_FIRST + IDHELP]; 



// ===== ,„=,, =================== z ============= 

// class NewEntryDlgCls 

// 

// Purpose : Displays new entry dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

class NewEntryDlgCls : public TDialog 

{ 

protected : 



long 

long 

PTRadioButton 

PTRadioButton 

PTRadioButton 

PTRadioButton 

PTRadioButton 

PTRadioButton 



NewX; 

NewY ; 

RadioTarget ; 

RadioGun ; 

RadioRadar ; 
RadioObservat ionPost ; 
RadioRegPoint ; 
RadioCheckMark; 
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public : 



NewEntryDlgCls ( PTWindowsObj ect AParent , 

LPSTR AName , 

long X, 

long Y) ; 

-NewEntryDlgCls ( ) ; 
virtual void SetupWindow () ; 

virtual void Ok(RTMessage Msg) = [ID_FIRST + IDOK]; 

virtual void Cancel ( RTMessage Msg) = [ID_FIRST + IDCANCEL]; 



//=============================================== 

// class NewFromEntryDlgCls 

// 

// Purpose : Displays new from entry dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//=============================================== 

class NewFromEntryDlgCls : public NewEntryDlgCls 

{ 

private : 



long 


FromX; 


long 


FromY ; 


int 


Of f Azimuth ; 


long 


Of fDistance; 


PTEdit 


EditEast ; 


PTEdit 


EditNorth; 


PTEdit 


EditAzimuth; 


PTEdit 


EditDistance ; 



public : 

NewFromEntryDlgCls ( PTWindowsObj ect 

LPSTR 

long 

long 

int 

long 

-NewFromEntryDlgCls ( ) ; 
virtual void SetupWindow () ; 
virtual void Ok (RTMessage Msg) 
virtual void Cancel (RTMessage Msg) 

} ; 



AParent , 
AName, 4 

X, 

Y, 

Azimuth, 
Distance) ; 



= [ ID_FIRST + IDOK] ; 

= [ ID_FIRST + IDCANCEL]; 



//== == ========= ==== = ========================== 

// class GunlnputDlgCls 

// 

// Purpose : Displays gun input dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
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// All Rights Reserved 

//=================================== 

class GunlnputDlgCls : public TDialog 

{ 

private : 



GunDBCls 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTComboBox 

PTComboBox 

PTComboBox 



aGun ; 

EditEast ; 
EditNorth; 
EditHeight ; 
EditRange ; 
EditLef t ; 
EditRight ; 
EditCommonDef ; 
EditOrientat ion ; 
ComboBattal ion ; 
ComboBa 1 1 e ry ; 
ComboGun ; 



PTComboBox ComboGunType ; 
PTBCheckBox CheckMainGun ; 



public : 



} ; 



GunlnputDlgCls ( PTWindowsObj ect AParent , 

LPSTR AName , 

long X, 

long Y) ; 

GunlnputDlgCls ( PTWindowsObj ect AParent , 

LPSTR AName , 

GunDBCls Gun) ; 

-GunlnputDlgCls ( ) ; 
virtual void SetupWindow ( ) ; 

virtual void Ok(RTMessage Msg) = [ID_FIRST 

virtual void Cancel (RTMessage Msg) = [ID_FIRST 
virtual void Help (RTMessage Msg) = [ID_FIRST 



IDOK] ; 

I DC AN CEL] 
IDHELP] ; 



//============================================= 

// class Target InputDlgCls ^ 

// Purpose : Displays target input dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//========= = = ============ ====== ================ 

class TargetlnputDlgCls : public TDialog 

{ 

private : 



TargetDBCls 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTComboBox 



aTarget ; 
EditTargetNo ; 
EditEast ; 
EditNorth; 
EditHeight ; 
EditDescription; 
ComboCategory ; 
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public : 



Target InputDlgCls ( PTWindowsObj ect 


AParent , 




LPSTR 


AName, 




long 


X, 




long 


Y) ; 




Target InputDlgCls ( PTWindowsObj ect 


AParent , 




LPSTR 


AName, 




TargetDBCls 


Tar) ; 




-Target InputDlgCls ( ) ; 
virtual void SetupWindow () ; 
virtual void Ok (RTMessage Msg) 


= [ ID_FIRST + 


IDOK] ; 


virtual void Cancel (RTMessage Msg) 


= [ ID_FIRST + 


IDCANCEL] ; 


virtual void Help (RTMessage Msg) 


= [ID_FIRST + 


IDHELP] ; 



//================================================ 

// class TargetDBDlgCls 

// 

// Purpose : Displays target database dialog box. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//================================================ 

class TargetDBDlgCls : public TDialog 

{ 

private : 

PTListBox ListNames; 

PTWindowsObj ect MainWnd; 

public : 



}; 



TargetDBDlgCls ( PTWindowsObj ect AParent , 
LPSTR AName) ; 

-TargetDBDlgCls ( ) ; 
virtual void SetupWindow () ; 
virtual void UpdateListBox ( ) ; 
virtual void ButtonAdd (RTMessage) = 
virtual void ButtonDelete (RTMessage ) = 
virtual void ButtonDetail (RTMessage) = 
virtual void ButtonShow (RTMessage) = 
virtual void Cancel (RTMessage) = 

virtual void Help (RTMessage) = 



[ ID_FIRST + 
[ID_FIRST + 
[ID_FIRST + 
[ID_FIRST + 
[ ID_FIRST + 
[ ID_FIRST + 



ID_ADD] ; 
ID_DELETE] ; 
ID_DETAIL] ; 
ID_SHOW] ; 
IDCANCEL] ; 
IDHELP] ; 



//=========== 

// class 
// 

// Purpose : 
// 

// Notes : 
// 

// Copyright: 
// 



GunDBDlgCls 

Displays gun database dialog box. 



Copyright (c) 1993, Mustafa ESER 
All Rights Reserved 
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//================================ 

class GunDBDlgCls : public TDialog 

{ 

private: 

PTListBox ListNames; 

PTWindowsObj ect MainWnd; 

public : 



GunDBDlgCls ( PTWindowsObj ect AParent , 
LPSTR AName) ; 

-GunDBDlgCls ( ) ; 
virtual void SetupWindow ( ) ; 
virtual void UpdateListBox ( ) ; 
virtual void But tonAdd (RTMes sage) 
virtual void ButtonDelete ( RTMessage) 
virtual void ButtonDetail (RTMessage) 
virtual void ButtonShow( RTMessage) 
virtual void Cancel (RTMessage) 
virtual void Help (RTMessage) 



[ ID_FIRST + 
[ ID_FIRST + 
[ ID_FIRST + 
[ ID_FIRST + 
[ID_FIRST + 
[ ID_FIRST + 



ID_ADD] ; 
ID_DELETE] ; 
ID_DETAIL] ; 
ID_SHOW] ; 
IDCANCEL] ; 
IDHELP) ; 



# end if CHART_H 



Listing B.3: DEFINES.H header file 



// 

// defines. h 

// 

// header file for defines 

//★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★-A-** 



#if ndef DEFINES_H 

# define DEFINES_H 



//menu identifiers 
#def ine CM_TRAININGMODE 101 

#def ine CM_EX I TC H ART 109 

#def ine CM_INSERT 203 

# define CM_INSERTFROM 204 

#def ine CM_GRIDSETUP 303 

#def ine CM_TARGETSETU P 3 04 

#def ine CM_GUNSETUP 305 

#def ine CM_SAVEONEXIT 309 

#def ine CM_DATABASETARGET 401 

#def ine CM_DATABASEGUN 402 

# define CM_AB0UT 151 
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//info window menu identifiers 



#def ine CMJ3CALE0NE 801 

#def ine CM_SCALETWO 802 

#def ine CM_SCALETHREE 803 

#def ine CM_SCALEFOUR 804 

#def ine CM_SCALEFIVE 805 

#def ine CM_SCALESIX 806 

//Grid setup dialog window 
#def ine ID_Z0NE 112 

#def ine ID_LEFT 105 

#def ine ID_B0TT0M 106 

#def ine ID_RIGHT 107 

#def ine ID_T0P 108 

#def ine ID_DISTANCE 204 

#def ine ID_SCALE 110 

#def ine ID_SHOWGRIDLINES 101 
#def ine ID_SHOWNORTHSIGN 102 

/ /TargetSetupDlgCls dialog window 
#def ine ID_SHOWTARGETS 110 



//GunSetupDlgCls dialog window 
#def ine ID_SHOWGUNCOVERINGS 101 

//NewEntryDlgCls dialog window 
#def ine ID_TARGET 101 

#def ine ID_GUN 102 

#def ine ID_RADAR 103 

#def ine ID_0BSERVATI0NP0ST 104 
#def ine ID_REGPOINT 105 

#def ine ID_CHECKMARK 106 

//NewFromEntryDlgCls dialog window 

//it uses id_east, id_north ( id_target, id_gun, id_others as well 

#def ine ID_EAST 201 

#def ine ID_N0RTH 202 

#def ine ID_AZIMUTH 203 

#def ine ID_OFFDISTANCE 111 



/ /GunlnputDlgCls dialog window 



#def ine ID_MAINGUN 999 
#def ine I D_B ATTERYNAME 1000 
#def ine ID_GUNN0 1001 
# define I D_BATTAL I ONNAME 1002 
#def ine ID_GUNTYPE 1005 
idefine ID_HEIGHT 1009 
#def ine I D_MAX RANGE 1010 
#def ine ID_MAXLEFT 1011 
#def ine ID_MAXRIGHT 3012 
#def ine I D_C OMMONDEF 1013 
#def ine ID_0RIENTATI0N 1014 



//TargetlnputDlgCls dialog window 



#def ine I D_TARGETNO 103 

#def ine ID_DESCRIPTION 107 

# define ID_CATEGORY 108 

//TargetDBDlgCls dialog window 
#def ine ID_NAMES 101 

#def ine ID_ADD 102 
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#def ine 


ID_ 


.DELETE 
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#def ine 


ID_ 


.DETAIL 


104 


#def ine 


ID_ 


.SHOW 
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#endif DEFINES_H 



Listing B.4: GEN2LIST.H header file 



// 

// gen21ist.h 

// 

// header file for the template classes 
// genOdList 

// genUdList 

j y**************************************+****************^*********** 



# i f nde f _GEN2 L I ST_H 
# define _GEN2LIST_H 

//note that the following code is executed only 
//if this file has not been previously included 



#include "abslist.h" 



//======================================== 

// template struct dListNode 

//======================================== 

template<class In- 
struct dListNode { 

T dataNode; 

dListNode<T> *prevPtr; 
dListNode<T> *nextPtr; 

} ; 



//========= 

// template 
// 

// Purpose 
// 

// 

// 

// 

// 

// 

// 

// 

// 



class genOdList 

: implements a classes of ordered doubly-linked lists 
with the following operations and features: 

> nodes with duplicate keys can be allowed. 

> insert new node. 

> search for a node with a specific occurrence 
of a key. 

> delete a node with a specific occurrence of a key. 

> traverse the nodes of the lists. 
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// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================ 



templatecclass T> 

class genOdList : public genAbstractList<T> 



{ 

protected : 

dListNode<T> 



T 



*nodePtr , 
*tail , 
*head; 
_buf 1 ; 



// node-visitation pointer 
// pointer to the tail of list 
// pointer to head of list 
// buffer 



genOdList<T>& copy ( genOdList<T>& ) ; 
publ ic : 

//state manipulation methods 
genOdList ( ) 

{ } 



genOdList (boolean canoverwrite, boolean al lowdupl icate ) ; 



genOdList (genOdList<T>& dl) 

{ 

head = NULL; copy(dl); 

} 



-genOdList ( ) 

{ 

clear ( ) ; 

} 



void setNodePtr (dListNode<T>* listPtr) ; 



void setBufl(T& newBufl) 

{ 

_buf 1 = newBufl; 

} 



//state query methods 
dListNode<T>* getNodePtrf) 
{ 

return nodePtr; 

} 



//object manipulation methods 
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virtual boolean insert (T&) ; 

virtual boolean remove (T& x, unsigned occur = 1) ; 



virtual boolean search (T& x, unsigned occur = 1) 

{ 

dListNode<T> *p; 
return search(p, x, occur); 

) 



virtual boolean search (dListNode<T>* &thisptr, 

T Sc x, 

unsigned occur = 1) ; 



virtual boolean visitFirstNode (T& x) ; 
boolean visitPrevNode (T& x) ; 
virtual boolean visitNextNode (T& x) ; 
boolean visitLastNode (T& x) ; 
virtual void clear (); 



genOdList<T>& operator = (genOdList<T>& dl) 

{ 

copy (dl) ; 
return *this; 

} 

} ; 



//========= 

// template 

// 

// Purpose 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// Notes 

// 



class genUdList 

: implements a classes of unordered doubly-linked lists 
with the following operations and features: 

> nodes with duplicate keys can be allowed. 

> insert new node. 

> search for a node with a specific occurrence 
of a key. 

> delete a node with a specific occurrence of a key. 

> traverse the nodes of the lists. 



// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//====== = ========= = = = == ======================= 



template<class T> 

class genUdList : public genOdList<T> 

{ 

publ ic : 



//state manipulation methods 
genUdList () {} 



genUdList (boolean canoverwrite , boolean allowduplicate ) 
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: genOdList<T> (canoverwrite, al lowdupl icate ) 

{ ) 



genUdList (genUdList<T>& dl) 

{ 

head = NULL; copy(dl); 

} 



//object manipulation methods 
virtual boolean insert (T&) ; 
virtual boolean search (dListNode<T>* 

T& 

unsigned 



Scthisptr , 
x, 

occur = 1 ) ; 



genUdList<T>& operator = (genUdList<T>& dl) 

{ 

copy (dl) ; 
return *this; 

) 

} ; 



#endif _GEN2 L I ST_H 



Listing B.5: GLOBALS.H header file 



//*************************•*:************** + ****■*:* + ******************* 

// 

// globals.h 

// 

// header file for the class GlobalCls and varibals 
//*******************************************^*********************** 



#ifndef GLOBALS_H 

# define GLOBALS_H 

//note that the following code is executed only 
//if this file has not been previously included 



#define FACTORSLIDE 250//the bigger the slower 



//============== ======== = == ====== ===== = ================== = = ====== === 

// class GlobalsCls 

// 

// Purpose : Holds the global objects and variables for the rest of 
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// the application. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//=================================================================== 

class GlobalsCls 

{ 

public : 

long WCLeft, WCBottom; //lower left most coors of world 

long VisibleWCLef t ; //left-most coordinate of screen 

long VisibleWCBottom; //bottom-most coordinate of screen 

long WCToRightExtension; // just for scroll bars limitations 

long WCToTopExtension; //just for scroll bar limitations 

int Distances [ 5] ; 

int CurrDi stance Index; 

short DistancesCount; 

long Scales [6]; 

int CurrSca le Index; 

short ScalesCount; 

BOOL ShowGrids; 

BOOL ShowNorthArrow; 

BOOL ShowTargets; 

BOOL S ho wGunCove rings ; 

BOOL SaveOnExit; 

int MinScaleNDXForGuns ; 

short CurrBmpButtonSelection ; //tool bar bitmap menu selections 
long SlideAmount.; //scroll bar sliding amount in meters 

//main window dimensions 
int WidthMa inWindow; 

int HeightMainWindow; 

// 

GlobalsCls ( ) 

// 

{ 

Reset ( ) ; 



// 

Reset ( ) 

// 

{ 



//firing chart extremum coordinates 
WCLeft = 10000; 

WCBottom = 10000; 


VisibleWCLef t 


= 


WCLeft; 


VisibleWCBottom 


- 


WCBottom; 


WCToRightExtens ion 


= 


50000; 


WCToTopExtension 


= 


50000; 


Distances [ 0 ] 




100; 


Distances [ 1 ] 


= 


500; 


Distances [2 ] 


= 


1000; 


Distances [3 ] 


= 


2000; 


Distances [4 ] 


= 


5000; 


CurrDi stance Index 


= 


2; 



106 



DistancesCount 
Scales [ 0 ] 
Scales [1] 
Scales [2 ] 
Scales [ 3 ] 
Scales [4 ] 
Scales [ 5 ] 
CurrScale Index 
ScalesCount 



5; 

2500; 

5000; 

12500; 

25000; 

50000; 

100000 ; 

2 ; 

6 ; 



ShowGrids = TRUE; 

ShowTargets = TRUE; 

ShowGunCoverings = TRUE; 

MinScaleNDXForGuns = 1; 

ShowNorthArrow = TRUE; 

SaveOnExit = TRUE; 



CurrBmpButtonSelection 



- 1 ; 



//means none of 



them is selected 



SlideAmount 
WidthMainWindow 
He ightMa inWindow 



Scales [CurrScalelndex] / FACTORSLIDE; 
800; 

600; 



} ; 



# end if GL0BALS_H 



Listing B.6: GUNDB.H header file 



//*****★*★**★****************★********★★***★*★★***★***★★★*★★*★**★★★★★ 

// 

// gundb .h 

// 

// header file for the class GunDBCls 

j y******+*************************************+********************** 



#if ndef _GUNDB_H 
# define _GUNDB_H 

//note that the following code is executed only 
//if this file has not been previously included 



#include <string.h> 



#def ine MAXNAMELEN 10 
# define MAXMODELLEN 30 



_CLASSDEF (GunDBCls ) 

// class GunDBCls 
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// 

// Purpose : Serves as database management class for gun database 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//=============================================================== 

class GunDBCls 

{ 

private : 



char 

char 

short 

long 

long 

int 

BOOL 

char 

long 

int 

int 

int 

int 



Battal ionName [MAXNAMELEN] ; 
Battery Name [MAXNAMELEN] ; 
GunNo ; 

CoorEast ; 

CoorNorth; 

Height; 

MainGun; 

Model [MAXMODELLEN] ; 

MaxRange ; 

MaxRightDef lection ; 
MaxLeftDef lection ; 
CommonOrientationDef lection ; 
OrientationDef lection; 



public : 



// 

GunDBCls () 

// 

{ 






strcpy (Battal ionName, "*"); 
BatteryName [ 0 ] 




NULL; 


GunNo 


= 


0; 


CoorEast 


= 


0; 


CoorNorth 


= 


0; 


Height 


= 


0; 


MainGun 


= 


0; 


strcpy (Model, 
MaxRange 


_ 


0; 


MaxRightDef lection 


= 


0; 


MaxLeftDef lection 


= 


0; 


CommonOrientationDef lection 


= 


0; 


OrientationDef lection 


= 


0; 



} 



// 

GunDBCls (char* 
char* 
int 
long 
long 
int 
BOOL 
char* 
long 
int 
int 



Btn, 

Btr, 

Gun, 

East, 

North, 

Height, 

mGun, 

Mod, 

Range , 

Def R, 

Def L, 
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// 

{ 



i nt CommonDe f , 

int Orientation) 



strcpy ( BattalionName, Btn); 

strcpy (BatteryName , Btr) ; 

GunNo 

CoorEast 

CoorNorth 

Height 

MainGun 

strcpy (Model , Mod); 

MaxRange 

MaxRightDef lection 
MaxLef tDe fleet ion 
CommonOrientat ionDef lection 
Or ientationDe flection 



Gun; 

East ; 

North; 

Height ; 
roGun ; 

Range ; 

Def R; 

Def L ; 

CommonDe f ; 
Orientation; 



// 

GunDBCls {const GunDBClsk T) 

// 



//copy initializer 
{ 

strcpy (BattalionName, T . Battal ionName ) ; 
strcpy (Bat tery Name, T . Battery Name ) ; 



GunNo 

CoorEast 

CoorNorth 

Height 

MainGun 

strcpy (Model , T. Model); 
MaxRange 

MaxRightDe fleet ion 
MaxLef tDe fleet ion 
CommonOrientat ionDef lection 
Or ientationDe fleet ion 



= T. GunNo; 

= T. CoorEast; 

= T. CoorNorth; 

= T. Height; 

= T. MainGun ; 

= T . MaxRange ; 

= T .MaxRightDef lection ; 

= T. MaxLef tDe fleet ion; 

= T . CommonOrientat ionDef lection ; 
= T . Orientat ionDef lection; 



// 

-GunDBCls { ) 

// 

O 



//assignment operator 

// 

GunDBClsSc operator = (const GunDBCls &T) 

// 

{ 

strcpy (BattalionName, T . BattalionName ) ; 
strcpy (BatteryName , T . Bat tery Name ) ; 



GunNo 

CoorEast 

CoorNorth 

Height 

MainGun 



T . GunNo ; 

T . CoorEast ; 
T. CoorNorth ; 
T . Height ; 

T. MainGun ; 



109 



strcpy (Model , T. Model ) ; 
MaxRange 

MaxRightDef lection 
MaxLef t Deflect ion 
CommonOrientationDef lection 
Or ientationDe flection 
return *this; 

} 



// 

int operator < (GunDBCls& aGun) 

// 

{ 

if( strcmp (BattalionName, aGun . Bat talionName) < 0 ) { 

return 1 ; 

}else if ( strcmp (BattalionName, aGun . BattalionName) == 0 ) { 

if ( strcmp (BatteryName, aGun . Bat tery Name) < 0 ) { 

return 1 ; 

}else if ( strcmp (BatteryName, aGun . BatteryName) == 0 ) { 

if ( GunNo < aGun.GunNo ) 
return 1 ; 

} 

} 

return 0 ; 



// 

int operator > (GunDBCls& aGun) 

// 

{ 

if( strcmp (BattalionName, aGun . BattalionName ) > 0 ) { 

return 1; 

Jelse if (strcmp (BattalionName, aGun . BattalionName) == 0 ) { 

if ( strcmp (BatteryName, aGun . BatteryName) > 0 ) { 

return 1; 

}else if ( strcmp (BatteryName , aGun . BatteryName) == 0 ) { 

if( GunNo > aGun.GunNo ) 
return 1; 

} 

} 

return 0 ; 



// 

int operator <= (GunDBCls& aGun) 

// 

{ 

if ( strcmp (BattalionName, aGun . BattalionName) o= 0 ) { 

return 1; 

Jelse if ( strcmp (BattalionName, aGun . BattalionName) == 0 ) { 

if (strcmp (BatteryName, aGun . BatteryName) <= 0 ) { 

return 1; 

}else if ( strcmp (BatteryName, aGun . BatteryName) == 0 ) { 

if( GunNo <= aGun.GunNo ) 
return 1 ; 



= T. MaxRange; 

= T. MaxRightDef lection; 

= T.MaxLeftDef lection; 

= T. CommonOrientationDef lection ; 
= T. OrientationDef lection; 
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} 



} 

return 0 ; 



// 

int operator == (GunDBCls& aGun) 

// 

{ 

if ( ! strcmp ( Bat tal ionName , aGun . Bat tal ionName) ) 
if ( ! strcmp (Bat teryName, aGun . Bat tery Name) ) 
if(GunNo == aGun.GunNo) 
return 1; 

return 0; 

} 



// functions to access 

char *GetBattal ionName ( ) 
char *GetBatteryName ( ) 
short GetGunNo ( ) 
long GetCoorEast ( ) 
long GetCoorNorth ( ) 
int GetHeight() 

BOOL isMainGun() 
char *GetModel ( ) 
long GetMaxRange ( ) 
int GetMaxRightDef lection ( ) 

int GetMaxLef tDef lection ( ) 

int GetCommonOrientat ionDef lection ( ) 

CommonOrientationDef lection; } 

int GetOrientationDef lection ( ) 



the data members 

{return BattalionName ; } 

{return BatteryName ; } 

{return GunNo; } 

{return CoorEast; } 

{return CoorNorth;} 

{return Height;} 

{return MainGun; } 

{return Model;} 

{return MaxRange ; } 

{return MaxRightDef lection; } 

{return MaxLef tDef lection; } 

{return 

{return Orientat ionDef lection 



// functions to set the data members 

void SetBattal ionName (char *in) 
void Set BatteryName (char *in) 
void SetGunNo ( short in) 
void SetCoorEast ( long in) 
void SetCoorNorth ( long in) 
void SetHeight ( int in) 
void SetMainGun ( BOOL in ) 
void SetModel (char *in) 
void SetMaxRange ( long in) 
void SetMaxLef tDef lection ( int in) 
void SetMaxRightDef lection ( int in) 
void SetCommonOrientationDef lection ( int in) 
{CommonOrientationDef lection = in;} 

void SetOrientat ionDef lection ( int in) 
in; } 



{strcpy (BattalionName, in) 
{strcpy (BatteryName, in);} 
{GunNo = in;} 

{CoorEast = in;} 

{CoorNorth = in;} 

{Height = in;} 

{MainGun = in;} 

{ strcpy (Model , in);} 

{MaxRange = in;} 

{MaxLef tDef lection = in;} 
{MaxRightDef lection = in;} 



{Or i en tat ionDef lection 



// 

void Reset ( ) 

// 

//resets all data members 

{ 
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BattalionName [ 0 ] 


= 


NULL; 


BatteryName [ 0 ] 


= 


NULL; 


GunNo 


= 


0; 


CoorEast 


= 


0; 


CoorNorth 


= 


0; 


Height 


= 


0; 


MainGun 


= 


0; 


strcpy (Model , 






MaxRange 


= 


0; 


MaxRightDef lection 


= 


0; 


MaxLe ft Deflection 


= 


0; 


CommonOrientat ionDe fleet ion 


= 


0; 


Orientat ionDe fleet ion 


= 


0; 



) ; 



# end if _GUNDB_H 



Listing B.7: INFO.H header file 



// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 



★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 



info .h 

header file for the classes Select ionToolCls 

DistanceToolCls 
NewToolCls 
NewTToolCls 
SearchToolCls 
PickToolCls 
InfoWndCls 
Too 1 BarWndC 1 s 
Canvas WndC Is 

★ ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★it** 



# i f ndef INFO_H 

# define INFO_H 

//note that the following code is executed only 
//if this file has not been previously included 



# include "chart .h" 



_CLASSDEF ( Select ionToolCls ) 

//=== ============= = === z ==== 

// class 

// 

// Purpose 

// 

// Notes 



Select ionToolCls 

Base class for selection button classes. 
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// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================ 

class SelectionToolCls 

{ 

protected : 

HCURSOR hCursor; 
public : 



Select ionToolCls ( ) {} 

long FindDistance ( long, long, long, long); 
int FindAzimuth ( long, long, long, long); 



//abstract methods, which will 
virtual void DoMou se Down ( long , 
virtual void DoMou s eMove ( long , 
virtual HCURSOR GetCursor ( ) 
virtual void Reset () 

} ; 



be implemented in derived classes, 
long) {} 
long) {} 

{return hCursor;} 

U 



_CLASSDEF (DistanceToolCls ) 
//============================================= 

// class DistanceToolCls 

// 

// Purpose : Behaves for the distance button. 

// 

// Notes 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//= = === == == === = == = ======= = ===================== 

class DistanceToolCls : public SelectionToolCls 

{ 

private : 

BOOL Cl ickedBefore ; 
long XI, Yl; 

long Distance; 

long Azimuth; 

HCURSOR hCursorl, hCursor2; 

public : 

DistanceToolCls (HCURSOR hCl, HCURSOR hC2 ) ; 
virtual void DoMouseDown ( long X, long Y) ; 
virtual void DoMou s eMove ( long X, long Y) ; 
virtual HCURSOR GetCursor ( ) ; 
virtual void Reset (); 

} ; 



_CLASSDEF ( NewToo 1C 1 s ) 

// class NewToo 1C Is 

// 
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// Purpose : Behaves for the new tool button. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================ 

class NewToolCls : public Select ionToolCls 

{ 

private : 

HCURSOR hCursorl ; 
public : 

NewToolCls (HCURSOR hCl); 
virtual void DoMouseDown ( long X, 
virtual void DoMouseMove (long X, 
virtual HCURSOR GetCursorO 
virtual void Reset ( ) ; 

} ; 



long Y) ; 
long Y) ; 

{return hCursorl;} 



_CLASSDEF ( NewTToo 1C 1 s ) 

//================================================= 

// class NewTToolCls 

// 

// Purpose : Behaves for the new from tool button. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//================================================: 

class NewTToolCls : public Select ionToolCls 

{ 

private : 

BOOL ClickedBefore ; 
long XI, Yl; 

HCURSOR hCursorl, hCursor2; 
long Distance; 

int Azimuth; 

public : 



NewTToolCls (HCURSOR hCl , HCURSOR hC2 ) ; 
virtual void DoMouseDown ( long X, long Y) ; 
virtual void DoMouseMove ( long X, long Y) ; 
virtual HCURSOR GetCursorO ; 
virtual void Reset (); 



_CLASSDEF ( 
//======== 

// class 

// 

// 

// 



Purpose 



SearchToolCls) 



SearchToolCls 

: Behaves for the search button. 
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// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================ 

class SearchToolCls : public Select ionToolCls 

{ 

private : 

HCURSOR hCursorl ; 
public : 

SearchToolCls (HCURSOR hCl) ; 
virtual void DoMouseDown ( long X, 
virtual void DoMouseMove ( long X, 
virtual HCURSOR GetCursorf) 
virtual void Reset (); 

} ; 



long Y) ; 
long Y) ; 

{return hCursorl;} 



_CLASSDEF ( PickToolCls ) 

//==============================,============== 

// class PickToolCls 

// 

// Purpose : Behaves for the pick tool button. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============================================= 

class PickToolCls : public Select ionToolCls 

{ 

private : 

HCURSOR hCursorl; 
public : 

PickToolCls (HCURSOR hCl) ; 
virtual void DoMouseDown ( long X, 
virtual void DoMouseMove ( long X, 
virtual HCURSOR GetCursor ( ) 
virtual void Reset (); 

} ; 



long Y) ; 
long Y) ; 

{return hCursorl;} 



InfoWndCls 



_CLASSDEF ( InfoWndCls ) 

// == = ===================== 

// class 

// 

// Purpose : Displays the info area at the bottom of the window. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 
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//=============================== 

class InfoWndCls : public TWindow 

{ 

private : 

RECT WndRect; 

PTScrollBar HorizantalScroll ; 



public : 



InfoWndCls ( PTWindowsObj ect AParent, LPSTR ATitle); 

-InfoWndCls ( ) ; 

virtual void SetupWindow () ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCT& ) ; 
virtual void WMSize (TMessage& ) ; 

virtual void WMLButtonDown (TMessage &Msg) = [WM_FIRST + 
WM_LBUTTONDOWN ] ; 



virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 



void 

void 

void 

void 

void 

void 

void 

void 

void 



MenuONE (RTMessage) 
MenuTWO (RTMessage) 
MenuTHREE ( RTMe s sage ) 
MenuFOUR (RTMessage) 
MenuFIVE (RTMessage) 
MenuSIX (RTMessage ) 
WMHScroll (RTMessage 
Displaylnfo (char *) ; 
DrawScaleButton ( ) ; 



= [ CM_FIRST 
= [CM_FIRST 
= [CM_FIRST 
= [CM_FIRST 
= [CM_FIRST 
= [CM_FIRST 
Msg) ; 



+ 

+ 

+ 

+ 

+ 

+ 



CM_SCALEONE ] ; 
CM_SCALETWO] ; 
CM_SCALETHREE] 
CM_SCALEFOUR] ; 
CM_S C ALEF I VE ] ; 
CM_SCALESIX] ; 



} ; 



ToolBarWndCls 



_CLASSDEF (ToolBarWndCls ) 

//=======================; 

// class 

// 

// Purpose : Displays the tool bar area at the right of the window. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//================================================================== 

class ToolBarWndCls : public TWindow 

{ 

private : 



RECT 

PTScrollBar 

HBITMAP 

HCURSOR 

PSelectionToolCls 



WndRect ; 

VerticalScroll ; 
hBitmap[5] ; 

hCursorFrom, hCursorTo, 
Select ionArray [ 5 ] ; 



hCursorPick; 



public : 



ToolBarWndCls (PTWindowsObj ect AParent, LPSTR ATitle); 

-ToolBarWndCls ( ) ; 

virtual void SetupWindow () ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCT& ) ; 
virtual void WMSize (TMessage& ) ; 
virtual void WMVScroll (RTMessage Msg) ; 

virtual void WMLButtonDown (TMessage &Msg) = [WM_FIRST + 
WM_LBUTTONDOWN ] ; 
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} ; 



_CLASSDEF (CanvasWndCls) 

//=============================================================== 

// class CanvasWndCls 

// 

// Purpose : Displays the drawing area which holds targets, gun 
// positions etc. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//==============================================================: 

class CanvasWndCls : public TWindow 

{ 

private : 

RECT WndRect ; 

HBITMAP TickMarkBmp; 

HBITMAP TickMarkMask; 



public : 



CanvasWndCls ( PTWindowsObj ect AParent, LPSTR ATitle) ; 

-CanvasWndCls ( ) ; 

virtual LPSTR GetClassName ( ) ; 

virtual void SetupWindow ( ) ; 

Paint ( HDC PaintDC, PAINTSTRUCT& ) ; 
WMLButtonDown (TMessage &Msg) = [WM_FIRST 



virtual void 
virtual void 

WM_LBUTTONDOWN ] 
virtual void 
virtual void 
virtual BOOL 
virtual BOOL 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 
virtual void 

} ; 



WMMouseMove (TMessage &Msg) = 

WMSetCursor (TMessage &Msg) = 

ReadTargetData ( ) ; 

ReadGunData { ) ; 

DisplayGuns (HDC hDC); 
DisplayGunLabels (HDC) ; 
DrawGrids (HDC hDC, RECT Rect) 
DisplayTargets (HDC hDC); 
DisplayTargetLabels (HDC hDC); 
DrawLocat ionLines { long, long) 
TestConstraints ( ) ; 



[WM^FIRST 

[WM_FIRST 



+ WM_MOUSEMOVE ] 
+ WM^SETCURSOR] 



#endif 



INFO H 



Listing B.8: TARGETDB.H header file 



yy******************************************************************* 

// 

// targetdb.h 

// 

// header file for the class TargetDBCls 

yy******************************************************************* 
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# i f nde f _TARGETDB_H 
# define _T ARGE TDB_H 

//note that the following code is executed only 
//if this file has not been previously included 



#include <string.h> 



#def ineMAXTARGETNOLENl 0 



#def ine MAXCOORLEN 10 

#def ineMAXDESLEN 50 

#def ineMAXCATLEN 50 

#def ine MAXBUF 50 



_CLASSDEF ( Targe tDBC Is ) 

//=================================================================== 

// class TargetDBCls 

// 

// Purpose : Serves as database management class for target database. 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//========= == ==== = = ============= === ===================== = ============ 

class TargetDBCls 

{ 



private : 




char 


Targe tNo [MAXTARGETNOLEN] ; 


long 


CoorEast ; 


long 


CoorNorth; 


int 


Height ; 


char 


Descript ion [MAXDESLEN] ; 


char 
public : 


Category [MAXCATLEN] ; 



// 

TargetDBCls ( ) 

// 

{ 




TargetNo [ 0 ] 


= NULL; 


CoorEast 


= 0; 


CoorNorth 


= 0; 


Height 


= 0; 


Description [ 0 ] 


= NULL; 


Category [ 0 ] 


= NULL; 



} 



// 

TargetDBCls (char* tn, 
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long 


ea, 


long 


no, 


int 


he, 


char* 


des , 


char* 


cat) 



{ 

strcpy (TargetNo, tn) ; 
CoorEast = ea; 

CoorNorth = no; 

Height = he; 

strcpy (Description, des) ; 
strcpy (Category , cat); 



// 

TargetDBCls (const TargetDBClsSc T) //copy initializer 

// 

{ 

strcpy (TargetNo, T.TargetNo) ; 

CoorEast = T. CoorEast; 

CoorNorth = T. CoorNorth ; 

Height = T.Height; 

strcpy (Descript ion, T. Descript ion) ; 

strcpy (Category , T. Category); 

} 



// 

-TargetDBCls ( ) 

// 

O 



// 

TargetDBClsSc operator = (const TargetDBCls ScT) 

// 

//assignment operator 

strcpy (TargetNo, T.TargetNo) ; 

CoorEast = T. CoorEast ; 

CoorNorth = T. CoorNorth; 

Height = T.Height; 

strcpy (Descript ion, T .Descript ion) ; 
strcpy (Category , T. Category) ; 
return *this; 

} 



// 

int operator < (TargetDBClsSc aTarget) 

// 

{ 

return strcmp (GetTargetNo ( ) , aTarget .GetTargetNo () ) < 0; 

} 
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// 

int operator > (TargetDBCls& aTarget) 

// 

{ 

return strcmp (GetTargetNo () , aTarget .GetTargetNo () ) > 0; 



// 

int operator <= (TargetDBCls& aTarget) 

// 

{ 

return strcmp (GetTargetNo () , aTarget . GetTargetNo () ) <= 0; 

} 

// 

int operator == (TargetDBCls&c aTarget) 

// 

{ 

return strcmp (GetTargetNo () # aTarget .GetTargetNo () ) == 0; 

) 



// functions to access the data members 

char* GetTargetNo ( ) {return TargetNo;} 
long GetCoorEast ( ) {return CoorEast; } 

long GetCoorNorth ( ) {return CoorNorth;} 
int GetHeight() {return Height;) 
char* GetDescript ion { ) {return Description;) 
char* GetCategory ( ) {return Category;) 

// functions to set the data members 

void SetTargetNo (char* tn) { strcpy (TargetNo, tn) ; ) 

void SetCoorEast ( long east) {CoorEast = east;) 

void SetCoorNorth ( long north) {CoorNorth = north;) 

void SetHeight ( int height) {Height = height;) 

void SetDescription (char* des) { strcpy (Description, des) ;} 

void SetCategory (char* cat) {strcpy (Category , cat);} 



// 

void Reset ( ) 

// 

{ 

TargetNo [ 0 ] 
CoorEast = 

CoorNorth 
Height 

Description [ 0] 
Category [ 0] 

} 



= NULL; 
0 ; 

= 0 ; 

= 0 ; 

= NULL; 
= NULL; 



) ; 



#endi f _TARGETDB_H 
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APPENDIX C. (DATABASE HEADER FILES LISTINGS) 



Listing C.1: DBGUN.H header file 



// 

// dbgun.h 

// 

// header file for the class DBGunCls 

j /★★*★★★**★★*★*****★★*★★★★★★★★★★★★*★★★★★★*★***★*★****★★***★*★*★★★**★* 



#if ndef __DBGUN_H 

# define _DBGUN_H 



#include "WStr.h* 
#include "Paradox. h" 



#def ine MAXNAMELEN 10 
#def ine MAXMODELLEN 30 



_CLASSDEF ( DBGunCls ) 

//================================================== 

// class DBGunCls 

// 

// Purpose : Performs database management for guns. 

// Notes : 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//================================================== 

class DBGunCls 

{ 

private : 

//# 1 
char 
char 
short 
long 
long 
int 
BOOL 
char 
long 
int 
int 
int 
int 
char 
/ / #14 

//Paradox table info 
ParadoxTable TableGuns; 



Bat talionName [MAXNAMELEN] ; 
Bat teryName [MAXNAMELEN] ? 
GunNo ; 

CoorEast ; 

CoorNorth; 

Height; 

MainGun; 

Model [MAXMODELLEN] ; 

MaxRange ; 

MaxRightDef lection ; 
MaxLeftDeflection; 
CommonOrientationDeflection; 
Orientat ionDe fleet ion; 

Fir ingTableName [MAXNAMELEN] ; 
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int 

LPSTR 

LPSTR 



nFields ; 
Names [14] ; 
Types [14] ; 



protected: 

void RecordToBuf f er ( ) ; 
public : 

DBGunCls (LPSTR TableName) ; 
-DBGunCls ( ) ; 



BOOL ReadFirst ( ) ; 

BOOL ReadLast ( ) ; 

BOOL ReadNext ( ) ; 

BOOL ReadPrev(); 

BOOL isTableEmpty ( ) ; 

BOOL isLast ( ) ; 

BOOL AddRecord ( ) ; 

BOOL UpdateRecord ( ) ; 

BOOL DeleteRecord ( ) ; 

BOOL SearchByKey ( char *Btn, char *Btr, int Gun) ; 
void Reset ( ) ; 



//functions to access the data members 

char *GetBattalionName ( ) {return BattalionName ; } 

void SetBattalio.nName (char *in) { strcpy (BattalionName, in) ;} 



char 


*GetBatteryName ( ) 


void 


SetBat teryName ( char * 


short 


GetGunNo ( ) 


void 


SetGunNo ( short in) 


long 


GetCoorEast ( ) 


void 


SetCoorEast ( long in) 


long 


GetCoorNorth ( ) 


void 


SetCoorNorth ( long in) 


int 


GetHeight ( ) 


void 


SetHeight ( int in) 


BOOL 


isMainGun ( ) 


void 


SetMainGun (BOOL in) 


char 


*GetModel ( ) 


void 


SetModel ( char *in) 


long 


GetMaxRange ( ) 


void 


SetMaxRange ( long in ) 



{return BatteryName ; } 
{strcpy (Bat teryName, in) ;} 

{return GunNo; ' 

{GunNo = in;} 

{return CoorEast;} 
{CoorEast = in;} 

{return CoorNorth; } 
{CoorNorth = in;} 

{return Height;} 

{Height = in;} 

{return MainGun; } 

{MainGun = in;} 

{return Model;} 

{ strcpy (Model , in);} 

{return MaxRange;} 
{MaxRange = in;} 



int GetMaxRightDef lection ( ) {return MaxRightDef lection; } 
void SetMaxLef tDef lection ( int in) {MaxLeftDef lection = in;} 

int GetMaxLef tDef lection ( ) {return MaxLeftDef lection; } 

void SetMaxRightDef lection ( int in) {MaxRightDef lection = in;} 
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int GetCommonOr ientat ion ( ) 

(return CommonOrientat ionDef lection ; } 
void SetCommonOr ientat ion ( int in) 

(CommonOrientat ionDef lection = in;) 

int GetOrientat ionDef lection ( ) (return Orientat ionDef lection ; ) 

void SetOrientationDef lection ( int in) (Orientat ionDef lection = in;) 



char *GetFir ingTableName ( ) 

void SetFir ingTableName (char *fn) 



(return Fir ingTableName ; ) 
(strcpy (Fir ingTableName, fn) ; } 



) ; 

#endif _DBGUN_H 



Listing C.2: DBTARGET.H header file 



j j’k'k'k'k’k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k’k’k'k'k'k'k'k’k'k'k'k'k 

II 

II dbtarget.h 

// 

// header file for the class DBTargetCls 

j 1**+***+***********************+********+***+*********************** 



# i f nde f _DB TARGE T_H 

# define _DB TARGE T_H 



# include "WStr.h" 

# include "Paradox. h" 



#def ine 


SUCCESS 


1 


#def ine 


FAIL 


0 


#def ine 


MAXTARGETNOLEN 


10 


#def ine 


MAXCOORLEN 


10 


#def ine 


MAXDESLEN 


50 


#def ine 


MAXCATLEN 


50 


#def ine 


MAXBUF 


50 



_CLASSDEF ( DBTargetCls ) 

//===================================================== 

// class DBTargetCls 

// 

// Purpose : Performs database management for targets. 
// Notes : 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

// = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = : = = = = = = = = = = = = = = = = = 
class DBTargetCls 
( 

private : 
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char Targe tNo [ MAXTARGETNOLEN ] ; 

double CoorEast; 
double CoorNorth; 
double Height; 

char Description [MAXDESLEN] ; 
char Category [MAXCATLEN] ; 

//Paradox table info 
ParadoxTable TableTargets ; 
int nFields; 

LPSTR Names [6]; 

LPSTR Types [ 6] ; 

protected : 

void RecordToBuf fer ( ) ; 
void Buf f erToRecord ( ) ; 

public : 

DBTargetCls (LPSTR TableName) ; 

-DBTargetCls ( ) ; 

BOOL ReadFirst ( ) ; 

BOOL ReadLast ( ) ; 

BOOL ReadNext ( ) ; 

BOOL ReadPrevO; 

BOOL isTableEmpty ( ) ; 

BOOL isLast(); 

BOOL AddRecord ( ) ; 

BOOL UpdateRecord ( ) ; 

BOOL DeleteRecord ( ) ; 

BOOL SearchByKey (char *Key) ; 

void Reset ( ) ; 

char *GetTargetNo ( ) (return TargetNo;} 

void SetTargetNo (char* tn) ( strcpy (TargetNo, tn) ; } 

double GetCoorEast ( ) (return CoorEast;} 

void SetCoorEast (double east) (CoorEast = east;} 

double GetCoorNorth ( ) (return CoorNorth;} 

void SetCoorNorth (double north) (CoorNorth = north;} 

double GetHeightO (return Height;} 

void SetHeight (double height) (Height = height;} 

char *GetDescript ion ( ) (return Description;} 

void SetDescript ion (char* des) { strcpy (Description, des) ; } 

char *GetCategory ( ) (return Category;} 

void SetCategory (char* cat) { strcpy ( Category , cat);} 



#endif _DBTARGET_H 
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Listing C.3: DBTBLF.H header file 



// 

// dbtbl_f . h 

// 

// header file for the clas DBTable_F_Cls 



# i f nde f DBTABLE_F_H 

# define DBTABLE_F_H 



#include "WStr.h" 

# include " Paradox. h" 



_CLASSDEF (DBTable_F_Cls) 

//=================================================================== 

// class DBTab 1 e_F_C 1 s 

// 

// Purpose : Performs database management for Table F of firing table 
// Notes : 

// Copyright: Copyright (c) 1993, Mustafa ESER 

// All Rights Reserved 

//=================================================================== 

class DBTab 1 e_F_C 1 s 

{ 

private : 



double Range; //0 

double Elevation; //I 

double FSf orGrazeBurst ; // 2 

double DFSperlOmDecHOB; //3 

double DRperlmilDElev; //4 

double Fork; / / 5 

double TimeOf Flight ; //6 

double AzimuthCorrDrif t ; 1/1 

double AzimuthCorrCrossWind; / /8 
double MuzzleVelocityDec ; //9 

double MuzzleVelocitylnc; //10 

double RangeWindHead; //ll 

double RangeWindTail ; //12 

double AirTempDec; //13 

double AirTempInc; //14 

double AirDensityDec; // 15 

double AirDensitylnc ; //16 

double ProjectileWeightDec; //17 

double Pro j ect ileWeight Inc ; //18 



//Paradox table info 
ParadoxTable Table_F; 
int nFields; 

LPSTR Names [ 18 ]; 

LPSTR Types [19]; 
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protected : 



void RecordToBuf f er ( ) ; 
public : 

DBTable_F_Cls (LPSTR TableName); 
~DBTable_F_Cls ( ) ; 

BOOL ReadFirst ( ) ; 

BOOL ReadLast ( ) ; 

BOOL ReadNext ( ) ; 

BOOL ReadPrev(); 

BOOL isTableEmpty ( ) ; 

BOOL isLast(); 

void Reset ( ) ; 

double FindElevat ion (double range) ; 

} ; 



# end if DBTABLE_F_H 



Listing C.4: PARADOX.H header file 



j jit**************** ****** -k -k * * * -k * * * -k ***** ± ******* -k * * -k * ± * * * -k ********** ± -k 

// 

/ / paradox . h 

// 

// header file for database engine inclusions 
//**★**★*★*★★***★**********★**★*★***************★*★*****★************ 



#i f ndef PARADOX_H 
# define PARADOX_H 



# include <alloc.h> 

# include <string.h> 

# include "PdoxEnging .h" 

# include "PdoxTable .h" 

# include "PdoxRecord .h" 

// Note the following code is only executed if 

// this file has not been previously included 



char *GetParadoxError ( int nError) ; 



#endif 
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Listing C.5: PDOXENG.H header file 



// 

// pdoxeng.h 

// 

// header file for the class Select ionWndCls 



#ifndef ParadoxEngine_H 
# define ParadoxEngine_H 

// Note the following code is only executed if 
// this file has not been previously included 



# include "pxengine . h" 

#if def BORLANDC 

//PC computer specific includes 
# include <owl.h> 

#endif 



#ifdef Unix 

// Unix computer specific includes 
#endif 



//============================================ 

// class ParadoxEngine 

// 

// Purpose : 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//== == z= = = = = === = = == =========================== 

_CLASSDEF (ParadoxEngine) 
class ParadoxEngine 
{ 

public : 

static Status; 

ParadoxEngine (LPSTR szAPlicat ion) ; 
-ParadoxEngine () ; 

) ; 



#endif ParadoxEngine_H 
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Listing C.6: PDOXREC.H header file 



//******************************************************************* 

// 

// pdoxrec.h 

// 

// header file for the class ParadoxRecord 
/ /★*★★★★★****★*★***★★★★★★★**★*★**★★****★*************★****★****★***** 



# i f nde f ParadoxRe cord_H 

# define ParadoxRecord_H 

// Note the following code is only executed if 
// this file has not been previously included 



# include <ctype.h> 

# include "PxEngine.h" 
#include "WStr.h" 



#if def BORLANDC • 

// PC computer specific includes 
#include <owl.h> 

#endif 



#ifdef Unix 

// Unix computer specific includes 
#endif 



_CLASSDEF ( ParadoxTable ) 

_C LASS DEF ( ParadoxRecord) 
//============================================= 

// class ParadoxRecord 

// 

// Purpose : 

// 

// Notes : 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 

//============== ====== ===== ==================== 

class ParadoxRecord 



{ 

private : 



ParadoxTable ParentTable ; 
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public : 



RECORDHANDLE HRecord; 
intStatus ; 

ParadoxRecord ( ParadoxTable ) ; 
virtual -ParadoxRecord (); 



void RawGet (void *, int BufferSize); 
void RaPut (void *, int BufferSize); 



WStr GetField 
WStr GetField 
void PutField 
void PutField 



( FIELDHANDLE FieldNumber) ; 

(LPSTR FieldName) ; 

(FIELDHANDLE FieldNumber , WStr) ; 
(LPSTR FieldName , WStr); 



int Update ( ) ; 
int Add (); 
int Read ( ) ; 



# include "PdoxTable .h" 



#endif ParadoxRecord_H 



Listing C.7: PDOXTAB.H header file 



//******************************************************************* 

// 

// Pdoxtab.h 

// 

// header file for the class ParadoxTable 



#ifndef ParadoxTable_H 
# define ParadoxTable_H 

// Note the following code is only executed if 
// this file has not been previously included 



#include 

#include 

#include 

#include 

#include 



<DIR . H> 

"WStr . h" 
"pxengine . h" 

" PdoxEngine . h" 
" PdoxRecord. h" 



#ifdef BORLANDC 
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// PC computer specific includes 
# inc lude<owl . h> 

#endif 



#ifdef Unix 

// Unix computer specific includes 
#endif 



_CLASSDEF ( ParadoxTable ) 



class 




ParadoxTable 


Purpose : 






Notes : 


- 




Copyright : 


Copyright 


(c) 1993, Mustafa ESER 




All Rights 


Reserved 



class ParadoxTable 



{ 

public : 

intStatus ; 

ParadoxRecord Record; 
TABLEHANDLE HTable; 



ParadoxTable (LPSTR TableName, 

int IndexField = 0, 
int nFields = 0, 
char *Names[] = NULL, 
char *Types[] = NULL); 
virtual -ParadoxTable (); 

void DeleteAll (); 



RECORDNUMBER TotalRecords (); 

RECORDNUMBER CurrentRecord ( ) ; 

void RecordUpdate ( ) ; 
void RecordDelete (); 
void RecordAdd ( ) ; 

void ReadFirst (); 
void ReadLast ( ) ; 
void ReadNext ( ) ; 
void ReadPrev ( ) ; 

void ReadRecord (RECORDNUMBER RecordNumber ) ; 

void IndexDelete (char *Field) ; 

void IndexDelete ( FIELDHANDLE FieldNumber) ; 

void IndexAdd (char *Field, int Mode = INCSECONDARY) ; 

void IndexAdd (FIELDHANDLE FieldNumber, int Mode = INCSECONDARY) ; 

void Find (WStr Match, LPSTR FieldName, int Mode = SEARCHFIRST) ; 
void Find (WStr Match, FIELDHANDLE FieldNumber, int Mode = SEARCHFIRST) 
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#endif ParadoxTable_H 



APPENDIX D. (SCREENS OF APPLICATIONS) 
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Screen 4: (OFire) Call for Fire dialog box. 
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Screen 5: (OFire) Fire order dialog box. 
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Screen 7: (OFire) Subsequent fire call dialog box. 
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Screen 8: (OFire) Time-on-target dialog boxes. The above dialog box set the time refering the 
present time, while the below one sets the exact time. 
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Screen 9: (OChart) The firing chart window. 






Screen 10: (OChart) Grid setup dialog box. 




Screen 11: (OChart) Both tartget and guns database dialog boxes. 
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Screen 12: (OChart) Target display setup dialog box. 




Screen 13: (OChart) Gun display setup dialog box. 
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Screen 14: (OChart) Input inquiry dialog box. 




Screen 15: (OChart) Input inquiry dialog box (refering to a point) 
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Screen 16: (OChart) Target input dialog box. 




Screen 17: Azimuth and distance distance display dialog box. 
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Screen 18: (OChart) Gun input dialog box. 
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